What us geeks dislike about it is much the same reason we dislike systemd: its an abstract layer between you and the configuration of your services/daemons. We like init.d in that we can script those daemons and even add on to those init scripts if we choose. Where as windows services puts this wall between you and that sweetness. And systemd is pushing us in that direction and OP's last comment in the summary is ringing more and more true.
Uh, tell me how to adjust an init.d script such that:
1. You add support for running the daemon with an ionice level which was missing from the original script.
AND
2. The next distro upgrade won't blow your changes away, and you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks?
I'll tell you how - the way smart admins have always done it, by keeping their changes in a different file stored in version control that get's merged with whatever's in /etc after a dist-upgrade. Seriously:
1. The server isn't getting a dist-upgrade every few weeks unless the admin is stupid already, in which case he's probably *for* systemd and not against it
2. It's all text files, hence easy to manage merges with scripts and view differences
and...
3. It's text files, hence a svn/git repo is going to contain all the configuration anyway, unless the admin is stupid already, in which case he's probably for systemd (again).
With systemd you just stick a drop-in in /etc and it will only override that one setting in the default unit - and there is no file collision. That's the beauty of declarative programming.
They say the same thing about excel spreadsheets. Most spreadsheets are still a hideous mess to maintain. I think you just proved the "against" argument.