Quoting Russell Coker (russell@coker.com.au):
The fast boot of systemd is good for servers.
The fast boot, deterministic behaviour, absence of dependency hairballs involving peculiar Freedesktop.org desktop software, and ability to debug problems of OpenRC is _terrific_ for servers.
There's a lot of complexity in SysVInit scripts.
Well, that's because it emerged from System V, which was a bureaucratic AT&T nightmare. About the only advantage it had over BSD-style inits was that an edit error in a single service script could (usually) not render the system inoperable as with the BSD rc.inet1 script, etc. What the world needed was something that abandoned baroque AT&T cruft, was capable of fielding asynchronous uevent and hotplug messaging, and at the same time wasn't a monstrous construct from people who think binary logging is a good idea and who've never met a superfluous dependency they didn't like. For example, OpenRC. Which fortunately is very easy to converge systems onto -- and is also portable, transparent, and stable. Touting systemd because it isn't an 'old-fashioned init system' and comparing it only to SysVInit is pretty much the same thing DJB fanboys do when they tout Qmail as better than an 'old-fashioned MTA system' like sendmail. I.e., it's a fake and artificial comparision, comparing only against one antique while ignoring modern, current competitors. For example, OpenRC.
The init situation was a lot simpler before SysVInit was introduced to Linux, strangely there weren't many complaints when SysVInit was introduced.
Actually, there were plenty. The problem was that few reasonable alternatives existed _at that time_. Fortunately, now we have such things as (to pick a few examples somewhat arbitrarily) Epoch, nosh, perp, runit, OpenRC, s6, uselessd -- which is actually a rather diverse collection: Epoch: Single-threaded init system designed for minimal footprint, compatibility and unified configuration. nosh: init scheme, somewhat DJB-ish perp: service manager/supervisor runit: init scheme _with_ service manager/supervisor OpenRC: dependency-based and event-driven init, BSD-ish s6: service manager/supervisor, DJB-ish a la daemontools monit: service manager/supervisor uselessd: truly modular and sanely scoped init forked from systemd v208 (in part to make the point using code about what's wrong with systemd's design, but in part to make lemonade from a lemon) My friend Steve Litt has posted a taxonomy. (http://www.troubleshooters.com/linux/init/features_and_benefits.htm) Like, suppose you don't want your init to toss decisions about whether someone is permitted to carry out an action to PolKit? Suppose you thought socket activation was cute in inetd/xinetd but there's a good reason we don't use it generally elsewhere and only an idiot like Poettering would put it as an init default? Suppose you have no confidence in system software from a desktop coder so dumb he thinks binary logging is a step forward? Suppose you want process supervision only for _selected_ processes and think it's dumb as a default? Suppose you think a cgroups manager is a great idea, but think it's dumb for such complex code to be part of process #1 when it doesn't need to be? You might want a lightweight, debuggable init that suited to task, rather than some code hairball from the author of Pulse Audio. OpenRC on Debian 8.0 Jessie is particularly nice, in my experience.