> runit employs a concept of a service directory, responsible for an individual service, which is a process to monitor and an optional log service
Hey look at that. The critique that systemd has a log daemon (why does init need a log daemon?) doesn't really fly. Also runit doesn't have the ability as I understand it to properly specify dependencies between components falling back to the crap of runlevels. You won't see it as a user. You see it consistently & repeatedly as an OS developer/maintainer & through slow boot times. Then you have upstart which has some dependency & parallelization effort.
The fundamental architectural flip that systemd takes is, as I understand it, that each service/process starts as needed & just blocks on I/O letting the kernel manage parallelism implicitly through synchronization mechanisms that are robust & easy to maintain rather than manual config files. There's a lot of complexity here. There's name discovery & registration so that when you have a dependency on you, you automatically start whenever a dependency tries to access you. The logging mechanism is because you want to make sure that logging is robust & functional. The binary mechanism is great because it drastically shrinks the size of the log files, reduces the overhead (printf format strings are expensive), & makes it easier to write tools to process them.
I'm not sure about the DNS & other binaries but I'm sure there are similar intrinsic architectural problems those tools are solving. Again, none of these are necessarily ones you see as an end user directly. You see it indirectly because a lot of diffuse time is spent finding/fixing bugs due that architecture (yes there are still bugs but they're of a different flavor, and, hopefully, bugs you'd have in either system.
BTW when I last looked at systemd, superficially it looked very very similar to launchctl in terms of design with many of the same benefits.