Here, the good idea is that ssh, like many other communication programs, just needs a stream socket (actually, it just needs two file descriptors; the fact that one socket provides both the reading channel and the writing channel is an API wart, but it can be worked with and is irrelevant here.)

Historically, ssh has been tied to TCP because only communications over the network require cryptography; but there's no intrinsic reason why it couldn't use another type of socket.

On the server side, this is already the case.

The sshd server can be run communicating via an arbitrary pair of file descriptors, no matter the socket type, via the -i option, for "inetd". People have shied away from inetd and xinetd because they were implemented in an insecure and inefficient way, but there was a genuinely good core idea in inetd: the fact that a server could simply read on stdin, write on stdout, and another program, called a "super-server", could just listen to a socket (of whatever type), accept connections, and spawn an instance of the server that doesn't care about the socket type, or even that it is talking to the network.

tcpserver, of djb's ucspi-tcp, already existed as an alternative to inetd back then; today, https://skarnet.org/software/s6-networking/s6-tcpserver.html offers the same functionality, with some improvements (and the benefit of actually being maintained).

The idea of using a super-server is as old as inetd, which is almost as old as Unix itself. It has huge benefits: it factorizes code, simplifying it a lot, and it makes testing the server easy: pipe some data into it, read the output, no networking involved. This is Unix the way it was intended: modular pieces that you can then combine to achieve your goals.

(Super-servers have drawbacks too. The major one is that they cannot be used when the server shares state between its connections. Another one is that spawning a process for every connection incurs a loss of performance, but on Linux nowadays, using posix_spawn() instead of fork() mitigates most of it. For sshd, not using a super-server allows sshd to precompute some of the exchange parameters and have them as shared state; this was a significant performance improvement in the early 2000s, but is much less relevant with modern CPUs.)

systemd took the genuinely good core idea of super-servers, wrapped it up in some bullshit, and called that socket activation.

Most of the time, when you read "socket activation" on one of Lennart's posts, remember: it's basically inetd, and the extra functionality is mostly there to lock you in. When he says "lazy socket activation rocks", he's really saying "the super-server model rocks". (Sometimes there's also fd-holding involved; this is a bit more complex but irrelevant here, we can talk about it another time.)