> The systemd debacle is what led me down a rabbit hole toward the BSD's.

As far as I can tell (not actually using Debian or Ubuntu myself), there was only a debacle in Debian and Ubuntu, because they took too long to decide, and ended up having to rush their migration.

All the other distros, that had better-planned migrations (Arch, Fedora, SUSE, etc. etc. etc.) had basically no issues migrating to systemd, and have benefited immensely from being able to ditch the maintenance overhead of diverging init systems and init scripts, all re-implementing the same new features with slightly different implementations due to previous slightly differing implementation details.

People will currently call out OpenRC as the one non-systemd approach that works (e.g. if you acknowledge that SysvInit no longer actually works because no-one uses if for all system initialisation, instead leting it delegate lots of control to other bits and pieces), but before systemd won, there were:
* SysVinit + RH-derived initscripts
* Sysvinit + SUSE-style initscripts
* Upstart
* OpenRC
* prcsys - parallel rc system (Mandrake and derivatives)

All of these had similarities, and small differences, e.g. they all tried to support dependency information in init script headers.

As a sysadmin, it was frustrating to:
* Have to read every init script to see where it read its defaults from, was it /etc/sysconfig/pkgname or /etc/default/daemonname . Did it support setting limits from the defaults file, or would you have to hack the script to support your bigger-than-the-maintainer-imagined environment.
* Debug where the application was logging to, if it didn't setup logging correctly by default.

As a maintainer of a package used on more than one distro, it was difficult to:
* Test your init script to ensure it worked on RH-based distros and SUSE and Debian and Ubuntu. While Upstart said it supports init scripts, it fails in some random way that doesn't occur on RH and SUSE.
* Setup logging correctly, as not all distros provided a helper script to setup the right logging daemon (syslogd, vs rsyslog vs syslog-ng etc.)

We won't talk about the more modern features such as cgroups etc., where only about 2 init systems support the feature adequately, and no distro or packager actually managed to support such advanced features on more than one init system, and certainly not more than one non-systemd system.

systemd mainly stays out of my way, but makes it easy to troubleshoot and customise daemon behaviour in a consistent fashion.

> But trying to wrap your head around systemd in even a few hours isn't reasonable.

You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports.

> The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.

You're comparing apples and oranges here, you should rather be comparing two release of the same distro, before and after systemd became the default, and you would have seen very little difference.