The road forward for systemd

* [x]inetd only allows you to load services either lazily (start service when first needed) or on demand (start service once per request). Systemd has a third option, to load a service at systemd startup, right after all sockets have been created. This third option is probably the one that will be used the most.
* [x]inetd handles network sockets, systemd also handles unix sockets and file systems in exactly the same way.
* Unlike upstart, systemd does not solve the problem of automatically restarting services if they go down.
* There is no dependency checking when stopping services, so I can't make it so that when I restart postgres, my web service will be automatically restarted too. Your solution is to fix all services that can't gracefully handle downtime in their dependent services. Your rationale is that they will run into that problem when the services are on different machines in the future anyway.
* Enabling systemd support in a daemon can be a fair bit of work since it requires the ability for the daemon to take over an already open socket instead of creating a new one, but many popular daemons already support this because it's what launchd does too. A service that supports launchd can be trivially ported to systemd.
* If one does not convert a server to systemd init and opts to use the sysvinit compatibility layer, boot performance will be unchanged, but one will still get the increased service control of cgroups.
* If service A takes a long time to start, and service B needs A and has a short time out, problems will ensue. This is likely to happen when A is a name server. There is currently no fix for this in systemd, service B needs to be patched to become more patient.
* Socket location configuration is usually moved from service config into the systemd init file for the service, thus in the common case there is no duplication of information. An exception to this is with services that have both a client and server part running on the same system, and the server part is started by systemd. In these cases, the client side of the service will need to duplicate the socket information somewhere.
* Theoretically, there is nothing preventing upstart from using the same socket trick that systemd and launchd uses, but the existence of pre/post startup scripts would mean that some amount of serialisation would still happen.

So, please, don't compare systemd with inetd too much, because that misses the core point.

If you don't see what the difference between systemd and inetd is, then please read the story again, particularly the part about "Parallelizing Socket Services".