Your post captures what most anti-systemd posts have in common: it spouts reasonably-sounding slogans ("Unix philosophy!", "dependency hell bad!") - which have nothing to do with how systemd actually works.
Take the supposed dependency hell. In reality, systemd has a fairly small number of dependencies, almost all of which are already ubiquitous on a modern Linux system (e.g. libacl), and many of which are optional (e.g. PAM). Gnome depending on systemd is hardly systemd's fault - if systemd provides useful functionality that Gnome wants to use, then why does that count against systemd? In any case, it's irrelevant for your "stripped down and hardened server", because surely you're not running Gnome there.
Or take the Unix philosophy. I'd say systemd (as in the PID 1 program) exemplifies the Unix philosophy: it does one thing, namely managing system services, and it does it really well. Now, systemd the *package* contains lots of other stuff, but most of it is optional. For instance, it does contain an NTP client now, but you don't have to use it. In fact, there even is a configure flag to disable it at build time. Also, the existence of systemd-timesyncd in no way prevents you from running whatever NTP client you want under systemd.
The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone. It cannot even tell me if a service is currently running.) Systemd can. It cannot imagine going back to a situation where I can't do "systemctl" or "systemd-cgls" to get an overview of what is running on a system, or do "systemctl status " to see the status of a service, including its most recent log messages.