Depends on how you use them - if you

read

one socket and it takes a long time for a message to arrive, the thread is blocked and can't

read

from another socket, even if data is already available there, so the other socket's can experience poor latency. If you do that on multiple threads, or never need to process I/O simultaneously on multiple sockets anyways, this is moot.

I'm gonna use thread-per-connection model with either Socket or SocketChannel, so I don't mind blocking the thread. I was just not sure if maybe SocketChannels were still preferable (maybe newer code, better usage of OS primitives, etc etc)

Right, not sure. The thread-per-connection model always has some overhead but that's not neccessarily bad

Yeah, googling around doesn't show that either is vastly better when having low concurrency... so I'll go with the simpler option

The thread synchronization can become so much hassle that async I/O can actually become easier