> A proper server needs that "accept" abstraction, which is completely missing from pipes.
You can receive file descriptors over a UNIX socket, but yeah. That said I don't see why a file descriptor is a good abstraction for a listening socket in the first place when you don't read() or write() to it.
TCP is complicated. But "stream based sockets" aren't "just" TCP (ex: Unix domain sockets fixes all of the "glitches" of TCP).
The important bit of "sockets", in general, is the concept of:
1. "Accepting" file descriptor (creates new file descriptors whenever someone is "connecting" to you).
2. Multiplexing and "juggling" those descriptors.
TCP fits this model, though with some low level quirks. Unix Domain Sockets are arguably the place to start, but most beginner programmers wouldn't find that useful (they really want internet connections).
-------------
Its difficult to make a "server" off of one pipe. Maybe two pipes (first pipe accepts requests and divvys out new pipes to work off of). But no matter how you do it, its wonky.
A proper server needs that "accept" abstraction, which is completely missing from pipes.