???

You have to put a socket into non-blocking mode to use select/poll. Well, you don't have to, but there have been bugs reported against some implementations that will cause select/poll to behave unpredictably or incorrectly if a blocking socket is placed into the select/poll list. So, you should use both.

Further, select is advisory only. So, even if select tells you that the socket "won't block" because it is readable/writeable, when you turn around and try to read/write more than is available in the appropriate TCP buffer from/to a blocking socket the call will still block. Select just tells you the socket can be read/written from/to, more accurately (for most implementations) it tells you the watermark set on the socket has been met for the operation. Typically that watermark is set at 1 byte for both read and write. Therefore, once a single byte can be read or written to the socket select/poll says it's readable/writable. So, if you immediately tried to read/write more than a byte, it's certainly possible (again if you didn't use O_NONBLOCK) that the call could block.

That said, in most implementations these watermarks can be changed. Some developers have tried using that to make their applications more efficient. For example, if knew a header (of size sz) needed to be read at the moment, I could set the read low water mark to sz. Select wouldn't say the socket was readable until sz bytes were available. Of course, this assumes there is enough TCP send/receive space to hold that. Unfortunately, I read some report that said their attempts to improve efficiency this way were thwarted by the fact that constantly changing the watermark was not efficient enough to be worth it.

Anyway...that's a little off topic, but the point is, I don't know how you can say you shouldn't use both. You should, and in some cases, have to use both.