Actually, systemd on servers is great. It brings reliability and transparency that was missing with SysV init.
My CentOS 7 OSD nodes will sometimes not complete booting because it's hung somewhere in the boot process. There is no way to tell systemd to continue, Ctrl + C doesn't do anything and there is no way to get into the system because sshd is still not running.
Booting it in debug mode to try and get more information makes the whole thing work.
Also, when a unit file gets stuck, it goes into this waiting loop, which is a giant pain in the behind... I want to try and fix it, not wait 10+ minutes for the unit files to time out.
Ctrl + C should immediately stop what it is trying to do and dump me into some sort of login shell so that I can then go and fix the issue...
I've also had issues on Ubuntu 16.04 because of third party software that doesn't correctly set up it's Requires/Wants/Before/After's and then systemd will happily hang the whole boot process. Worst thing is that these issues become more and more apparent on systems with more cores/CPU's... so the 44 core, 88 thread systems we have show the issue way more than the 4 thread desktop that developers are using...
Systemd in their infinite wisdom decided that journald can choose when to log and when not to log something. Historically, syslog etc have been a very thin barrier between programs and outputting logs. Journald now decides if and as and when it's going to bother putting logging data to disk.
One of the things they've decided is you don't really need logs when you run the reboot command. In fact, if you really want logs you have to dig in to their documentation to find this: https://freedesktop.org/wiki/Software/systemd/Debugging/#ind...
That tells you to adjust kernel parameters and write a file to disk to explicitly re-enable logging.
I lost a whole bunch of time recently troubleshooting something on a server running systemd that was interfering with the reboot process, because systemd logged sweet FA. I had a pretty good idea what the problem was, but lack of logs made it significantly harder to nail down. The actual problem is one I've run into all sorts of times in the past, and in every non-systemd case, there's always been enough detail in the logs from the init system to nail it precisely from the get go.