"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
That kill apache, not the crap it started and that forked itself away.
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.
That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)
I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?
With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.
A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
Read a couple of man-pages and see for yourself.