>> Actually, this is the core issue: systemd, as a complete replacement,
>> makes all these years of experience obsolete and irrelevant.
No it does not. Your /etc/rcX.d/SYY.foobar script still works as-is. In fact, on Debian (if it uses the LSB functions) it transparently redirects itself to systemd, so your basic "/etc/init.d/foobar restart" invocation stanza does the right thing.
Your assertion that
>> most of the new functionality could be implemented without
>> a complete eradication of SysV concepts.
is misleading. Most, probably. All, no way. Just read the systemd.service manpage. Lots of what it can do require assistance from /sbin/init; when you're done implementing all of that, and then write another heap of fragile helper programs along the lines of Debian's(?) start-stop-daemon to do whatever can be done withoout /bin/init's help, you have basically created a wholly new startup system anyway. So, you can just as well drop that idea and use systemd. :-P
Just answering the question "is server FOO running" in traditional SysV is an exercise in fragility. PID file exists? Contents match a running process? With the same executable and/or process name? (Oops, does your SysV init script checks THAT? What happens if you rename inetd to inetd.OLD before restarting?)
If not, can we safely restart it – are all its child processes dead yet? What if two sysadmins restart a service at roughly the same time, would that cause a problem?
And so on.
Yeah, we old fogeys need to learn a few new magic incantations, but let's face it: they are a whole lot less fragile than the ones they replace, and they tell us a lot more about the state of the system. Given the choice between what "systemd status foo" does for me and what I had to do before to figure out what's going on (grep through ps, verify that the server I do see doesn't happen to run in some chroot-ish namespace, grep through a few syslog files), the choice is a no-brainer. Even for me.