Sure Systemd somewhat goes against the Unix philosophy of "Build something that does one thing well" but, as many have pointed out before, Systemd is not really one monolithic project, but a number of smaller project s all unified under the banner of Systemd and designed to work well together. I may not like EVERYTHING Systemd does but I can respect that it has simplified and standardized how things are done on Linux as well as enabling stuff that couldn't be done before.
The Unix philosophy ship sailed a long long time ago. I recall a quote from Rob Pike along the lines of "Perl killed it". I can't find the exact quote, or I'd include it here with proper citation. The Unix philosophy is sometimes useful, but I'm no absolutist. I live inside emacs a lot of the time, so of course I'm not.
I've heard at least one rando on the net say it's hypocritical to love emacs and hate systemd. I call BS. Here's the difference. Systemd is a honking huge C codebase. That's all it is: an enormous pile of C. Emacs, on the other hand, has a small C core: a Lisp interpreter and some primitives. The really exciting stuff doesn't happen in C; it happens in Emacs Lisp. The two things are not comparable.
Systemd also brings a bunch of C dependencies, like dbus and glib. I've worked in a codebase that used glib. I do not love it, and I mistrust the safety of things that use it. GLib is what happens when C partisans try to add C++ features to C.
The "init system" part of systemd replaced a bunch of stuff that was previously written in shell. The shell scripts used by sysvinit on Red Hat and Debian derived distributions were absolutely terrible. Even Arch Linux init scripts were kinda bad. I used to write those things; I was an Arch packager for a few years. OpenRC init scripts and BSD init scripts are nicer. But on the whole, systemd was an improvement for most Linux distributions.
The problem is that systemd replaced piles of terrible shell with a big pile of C. Terrible shell scripts are at least debuggable by most sysadmins. 350K LOC C codebases, not so much. Systemd also makes the boot process highly nondeterministic. Nondeterminism in a system makes the system more difficult to reason about. Things that are hard to reason about are hard to debug.
All that being said, the init system I really like is dinit. It's a C++ codebase with no dependencies. It is also small and has a well-defined scope: system and service management. It uses its own service file format, which is basically lines of key-value pairs. Some of the very same complaints I've made against systemd in the previous paragraph could be made against dinit. But dinit seems to be a much more approachable system to me. I've used it for a couple years and have found it to be reliable and robust. I'm inconsistent, I know, so sue me.
Here's the dinit service that starts my Gemini server.
type = process command = /usr/local/bin/cmb-gemini-server restart = true depends-on = networking
For all the shouting GNU does about not focusing on "Linux" and being able to swap out the kernel for theirs, the OS itself seemed to be less important than the `init` your system ran.
It's worth noting here that GNOME is not part of GNU. It was at one time, but now it isn't. There's a huge overlap between Red Hat, GNOME, freedesktop.org, and systemd. The creator of systemd has publicly expressed disdain for the BSDs. The operating system that the Linux companies are pushing is essentially Linux+GNU+systemd+Wayland+GNOME. And we thought GNU/Linux was a mouthful?
In fact, GNU is doing its own thing with guix. Their Guix System uses Linux as the kernel and GNU Shepherd as the init system. Shepherd is written in Guile, so service definitions are essentially Scheme programs. I'm a Schemer, so this sounds pretty cool. Unfortunately, GNU has a tendency to overengineer and to let engineering be a tool of ideology. Hence I'm more strongly drawn to FreeBSD these days. I can say in the same breath that I have a great deal of respect for GNU. Let's not tarnish their gname on account of guilt by former gassociation.