I'm not super interested in rehashing the flamewar, so this is anecdata: from the perspective of sysadmin of thousands of physical machines, systemd has been a godsend. It gives me a standard way to supervise, gather log output from, and restart long-running-processes with dependencies on other processes. It's replaced a number of "sleep 10"s and "sleep 60"s that our infrastructure has grown over the years in shell scripts at various points in init. Starting services in a consistent environment (not inheriting anything from the sysadmin's own session / environment) has also been useful in an environment with lots of sysadmins.

It's certainly not the best solution out there for any single thing it does, but the standardization - i.e., that it is integrated with my distro and also every other distro - is extremely useful. Most existing things I want to run tend to have systemd support, and most homegrown things are very easy to write systemd units for.

Also, there are a lot of reasons to want fast reboots for servers, and systemd provides this. (Again, so do other approaches, but the standardization means this actually happens.)

It's worth noting that there are sort of two debates: systemd vs. other similar systems (upstart, SMF, launchd, whatever) or systemd/similar systems vs. sysvinit. From experienced, large-scale UNIX admins, I think the wide consensus is that the answer to the second question is "definitely anything other than sysvinit". See, for instance, that the Debian tech committee debate was about systemd vs. upstart vs. insserv or something else, and nobody voted for sysvinit.