I think that is a good thing, isn't it?

Oh hey it's the same nonsense people have been saying for a decade now.

First of all, Linux is not Unix, and Unix principles were developed in like the fuckin 80s when what a computer is and does was different from what it is and does today. I'm betting you also use other software that doesn't follow the 'Unix' philosophy all the damn time, like, I dunno, the browser you used to post this nonsense. It was a guiding principle, not meant to be a dogmatic religious ideology. Also it not being the best choice for low memory embedded devices doesn't mean anything. It was designed for the desktop. These are very different platforms with very different needs. That's like complaining that the wheels on my car don't let it fly.

Also, bent the knee to who?

Really? Okay, so curl. You use it everyday. How's that using 'unix' principles?

You're just parroting the same old tired arguments.

That old load of bullshit again. You could swap out the logs if you want a shittier, less searchable (but text based) logging system. The rest can be countered in a similarly conclusive way, and has been repeatedly in the last decade or so.

Inform yourself before copy-pasting misinformation and misleading propaganda.

Sleep doesn't work well in some environments, like right now my current one using AMD+AMD hardware on EndeavourOS. Therefore I do boot. And couldn't care less for 10 seconds faster or slower boot times.

Ever really destroyed your server because the it needed were available? I have. It was so much worse than a boot process that froze.

If Systemd was pausing due to a network share being down, it's only because I (or you) told it to do exactly that. There are lots of good reasons to delay the boot process until all drives the system expects to be there are actually there or the network is up. Cleaning up the mess that happens when the system does not check these kinds of things at boot is so much worse. It's never really some nebulous thing. Like it or not, intentional or not, the machine is doing exactly what you asked it to do and a delayed boot or a boot halted until you can solve the real problem is almost always better (or at least safer) than the alternatives. I've experienced all the things you've mentioned, dealt with each of those issues, and it was so much more of a hassle to diagnose before Systemd.

If you are having those issues with booting maybe it is because you configured your network share incorrectly? If you are waiting on shutdown timeouts for something then just go edit the timeout. systemctl edit <stuck thing>.

Typically when I crawl through journald it is to diagnose a problem with a specific application. Actually, the fact that those logs are easily accessible in a centralized place with easy to understand commands to access them is a reason why systemd (or more specifically systemd-journald) is so great.

The only times that I have had major issues like that was either because (A) I misconfigured something or (B) a package came misconfigured.

My system once refused to boot, because I deleted a partition and didn't remove it from fstab. Thankfully it was an easy and fast fix but I would expect it to just boot and give an error.