Here is one answer from an Arch developer about why they adopted systemd:
My personal feeling is this: systemd might be a software blackhole that eventually eat and destroy everything it comes close to and that's OK. If it is so bad then other developers can create a new or modified system that keeps the good stuff and eliminates the bad stuff, while working with other software projects to integrate better.
If we're stuck with systemd, is is better than others worse than some and it isn't like it is the first highly opinionated software project to grace us. A new ecosystem will get developed, wikis written, books sold, training courses packaged. Wise developers of other software will whisper in dark corners about the evil that stalks the land in the form of bad code and design of systemd, and crazed developers will haunt Slashdot, Hacker News, and LWN holding up the hand-lettered signs to make sure we understand how terrible Lennartitis is.
If something new comes along (more modular! less Lennart! doesn't insult the tender heart of tmux developers) developers will fight it out and we can go back to the 5 init systems that we're currently using.
OTOH, Nosh offers a tool to auto-convert service files into equivalent daemontools shell scripts:
Few seems to care enough either.
History of modern init FYI: http://blog.darknedgy.net/technology/2015/09/05/0/
And as the concept of containers and *aaS/cloud took hold, some of the same things that benefited said laptops was found to benefit containers.
The reason systemd happened over any of the others though was that perhaps the main dev had a penchant for NIH solutions, and worked for the 800 pound gorilla of the Linux ecosystem...
"From 2brainz (Former Arch Linux Developer for Init Scripts"
> I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts.
Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another.
In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent.
With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd.
Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies).
Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks.
The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well.
No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups.
Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it.
Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking.
Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us.
I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does.
So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution.
I could go on for hours, but this should be a good summary.
Most of the arguments against systemd are emotional arguments.