The UNIX philosophy is theoretically "do one thing and do it well", but in practice means "create small, composable pieces which can be used together or separately to accomplish what you need."
"systemd" the project is certainly huge and all-encompassing, but you could say the same thing about GNOME, the GNU project, or even GCC itself. The systemd project, however, is divided up into a ton of smaller components, all of which are relatively easy to understand in isolation and which almost universally have clear interoperations with each other.
Case in point: systemd ships two components, systemd-networkd and systemd-resolved. I typically reconfigure my systems to use these, as I find the documentation simple to understand and the config file easy to write by hand, even from memory. Compare this to, say, netplan, which I've never actually googled a full list of options for.
That said, both of them are optional, and Ubuntu 16.04 for example used systemd in what was apparently as few places as possible, notably not using systemd-networkd or systemd-resolved. They were easy to enable and use, but they were by no means necessary.
LIkewise, systemd ships systemd-machined, a framework for creating "machines", which are containerized systems which operate like virtualized systems, with their own copy of (probably) systemd running inside.
The systemd tools, like systemctl and journalctl, can interact directly with these machines, meaning that you can use the same tools on the same command-lines to access what is effectively a "containerized" system's logs in the same way that you would locally. Likewise, systemd-networkd has configuration to automatically bring up their network configs as soon as they're created, without having to do anything manually. Again, it's not shipped by default and definitely not enabled by default.
In this way, I would say that systemd actually embodies the so-called "UNIX philosophy", by creating a bunch of separate daemons and systems, all of which can work well together but few of which are inherently required by each other. It also adds a ton of functionality which is effectively impossible to add to existing init.d systems in any maintainable way (like spawning processes in their own cgroups and namespaces, creating ephemeral users with arbitrary UIDs for those processes, creating private /tmp directories for individual services, adding bind mounts, restricting syscalls, mounting the root filesystem read only, and so on.
In essence, systemd gives you all the tools you need to build up whatever system management you want, but if you just want "execute this binary, which will not fork, and keep it running" then you can do that too, without any of those extra features getting in the way.
Fwiw, the same disease infected gnome a long time ago as well. One day my key bindings surprisingly changed from unix to windows style in an update. Then I lost the ability to customize the widgets surrounding windows by the window manager. Control over focus follows mouse was lost... It drove me away as a user because my preferences were no longer worth supporting.
I guess I'm just turning into a grey beard at this point. Sigh.
Because one of your other services has said it depends on network.target/network-online.target and is in the critical path of your boot. Check which one with "systemd-analyze plot > plot.svg" and "systemd-analyze dot 'network.*' | dot -Tsvg >network.svg". You can also see the critical chain and which parts block faster boot with "systemd-analyze critical-chain".
I think if you stopped expecting systemd to act like something else and instead treated it like the toolkit that it is you'd see that it does what it says it does quite well. Those issues with boot you mentioned are often that the distro ships a bad systemd config for a certain program.
What is the correct action for systemd to take here? After a timeout it will do what you said it will do, but until then it will try to do what the configs have said it should do.
You can tweak this however you want. You can shorten the timeout to whatever you want, you can change the dependency graph so that particular unit does not depend on the network, you can disable it completely.
> It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.
I don't understand what you mean here, it was configured to do one thing, and it did that thing. You can of course say that it's a bad config (which is probably true), but then it's either the distro, the packager, systemd's defaults (which often are not ideal) or your own customizations. I'm all for arguing about better defaults in systemd and making distros better config their packages, but the actual systemd init seems to have done exactly what it was told to do here. Again, I'd like to say that distros/packages/users of systemd treat it like a pure init and often don't use it as intended.
> I can't run systemd-analyze when the system off in lala-land for 5+ minutes.
If the tree of critical services for your boot are that broken I'd assume you need to boot into single user mode or use a recovery usb. But if you actually boot after those 5min I'd expect you to easily find where those 5mins where lost using the tools I mentioned above, which is more than I can say for previous inits.
Those who do not try to understand history are doomed to repeat it. That has clearly happened in the case of systemd and is why I don't think the attitude it presents towards end users is at the level that such a core piece of infrastructure should display.
Maybe your distro supports LDAP or another remote user directory? Maybe you just have some services installed that depend on the network and that say they are critical to the multi-user.target? You haven't given enough info for me to know, but it probably isn't systemd's fault in this case.
Except they are not composable on a package managing level. At least they weren't Debian, back when I tried.
You cannot just pick some. Update a wrong package, and the whole systemd monolith came in via dependencies, throwing out the old initd system.
Add to that the amount of new bugs that always come in when you write something new, and you have a very unpleasant experience.
Add to that the "I don't care what other people think, I do it MY way, and now you all also have to do it my way, if you want or not" attitude, and I switched to Devuan and never looked back.
Systemd has lots of goods ideas. And the existing alternatives are really sucky in places (but at least you know where they suck, can can deal with it).
If they really had written a small init system, and allowed pick-and-choose replacement of other parts, it would have been awesome. But they didn't.
Also, I find it strange how folks randomly get hung up on “Unix philosophy” without consistency, or regard for relevance (Per the Unix philosophy, you should not be checking email on a browser meant for webpages). It’s not like Unix is some pinnacle of system design. It was a good thing for 50 years ago, but our computers and our needs have evolved significantly since then.