> The Server Space is arguably the main place SystemD was designed for, and probably the only place it makes sense to deploy it.

I have the opposite opinion. systemd is irrelevant on a server (might've been relevant once upon a time, but not in this day and age), and it was developed specifically with end-user devices in mind.

Looking at the list of things systemd does (pulled from http://without-systemd.org/wiki/index.php/Arguments_against_... ):

systemd is an init system

In this day and age of virtual machines and containers, this is not really that useful. Most daemons are effectively PID 1 in their respective containers (if there is a separate init, it ain't really doing much besides launching a finger-countable number of daemons), and on the host (assuming you even can access the host) it's still stripped down to the bare minimum (with anything not required for managing VMs delegated to VMs instead of running directly on the hypervisor). As the article mentioned, the startup speed benefits from launching daemons in parallel are hardly useful compared to the long POST times and the limited number of daemons.

In contrast, desktops (niche systems like Qubes notwithstanding) do frequently run a lot of daemons on a single logical system. Fast startup does matter for desktops. systemd is actually useful here.

systemd provides an UEFI boot loader, systemd-boot (previously gummiboot)

Not really sure this is useful anywhere (ain't like there aren't plenty of existing bootloaders).

systemd provides a login manager, systemd-logind

Given - again - the growing trend toward virtualizing/containerizing everything, this is decreasingly valuable on a server except maybe for SSH logins (and even then). This is more useful for desktops, where login and session management matters a lot more.

systemd provides a syslog daemon, systemd-journald

Most servers shouldn't be using the vast majority of journald's functionality; they should instead be sending logs to a remote log server (if your servers aren't already doing so, then I suggest getting off Hacker News and fixing that ASAP :) ).

Desktops, on the other hand, typically stick to local logging and thus do potentially benefit from an improved local logging system (whether journald counts as "improved" is a matter of taste).

systemd provides a mount front-end, systemd-mount
[ ... ]
systemd provides automount via systemd.automount to substitute autofs

This one happens to be useful for both servers and desktops, but in my experience frequent live unmounting/remounting of disks is way more common for desktops than servers (with the sole exception of servers hooked up to, say, an optical media carousel or something like that, and even that's a pretty niche application). RAID wouldn't even be a factor here, since swapping out a disk in an array doesn't involve mounting or unmounting the filesystem(s) on top of that array.

The udev sources were merged into the systemd source tree.

Benefits servers and desktops more-or-less equally.

systemd provides systemd.timer timer units, which can be used to replace cron and at

One of the few cases of a systemd feature that's more useful on servers than desktops (though in both cases I've yet to see this actually used instead of cron/at).

systemd provides a D-Bus client library, sd-bus (see sd-bus)
systemd developed an in-kernel D-Bus implementation, kdbus.

D-Bus literally stands for "Desktop Bus". These are explicitly desktop-oriented features.

systemd provides a caching DNS resolver, systemd-resolved

This is entirely useless on a server; either your server is a DNS server (in which case it's using an actual DNS-serving daemon meant for handling external traffic, i.e. not systemd-resolved) or it's not a DNS server (in which case - unless you're an extreme masochist and consider DNS-cache-related issues to be fun - you're probably going to be pointing /etc/resolv.conf at your network's actual DNS servers and calling it a day).

This is way more useful for laptops and mobile devices, which switch networks frequently (and sometimes switch onto e.g. public hotspots or other networks with buggy or overworked or outright adversarial DNS servers of their own).

systemd provides a network manager and DHCP client, systemd-networkd
systemd provides a HTTP server for journal events, systemd-journal-gatewayd
systemd provides a containerization system systemd-nspawn

Not sure if I've ever seen these three actually used anywhere; they seem to be equally useless on servers and desktops.

----

Final verdict given the above: systemd was demonstrably developed specifically with desktops in mind (and even more specifically with GNOME in mind, which should be unsurprising given how much Red Hat loves GNOME). The vast majority of its components make far more sense on end-user devices than servers (and the ones that don't are either equally useful or equally useless).