Why can't use C standard I/O with sockets

You can certainly use stdio with sockets. You can even write a program that uses nothing but stdin and stdout, run it from inetd (which provides a socket on STDIN_FILENO and STDOUT_FILENO), and it works even though it doesn't contain any socket code at all.

What you can't do is mix buffered I/O with select or poll because there is no fselect or fpoll working on FILE *'s and you can't even implement one yourself because there's no standard way of querying a FILE * to find out whether its input buffer is empty.

As soon as you need to handle multiple connections, stdio is not good enough.

It's totally fine when you have simple scenario with one socket in blocking mode and your application protocol is text-based.

It quickly becomes a huge pain with more then one or non-blocking socket(s), with any sort of binary encoding, and with any real performance requirements.

Do not know any direct objection. Most likely this will work fine.

At the same time I can imagine that a platform, where fprintf() and fscanf() have their own buffers, staying above the file descriptor layer. You may not be able to flush these buffers.

It is hard to speak about all possible platforms. This means that it is better to avoid this with sockets.

At the end of the day the app program should solve the app problem. It should not be a compiler/library test.