> There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.
I work on a distribution (openSUSE) and don't hold systemd in high regard. There are many people who work for distributions and don't feel that way. Of course, the general openSUSE community decided to go with systemd, but it's not fair to claim that everyone who contributes to distributions that use systemd must therefore like systemd.
The reason I don't like systemd is that in my experience, systemd forces you to integrate system management programs (such as container runtimes) with systemd. And when you are forced to integrate, systemd then causes you nothing but issues. cgroups are a perfect example of this. In addition, systemd doesn't obey SIGPWR and as a result LXC has to write special code for systemd -- which is just ludicrous.
I've talked to some other people from other distributions and they feel so strongly against this that it's possible you'll see a new init system in a few years that rectifies the problems with systemd.
> an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing
There are several things wrong with that description of systemd. To be clear, the pre-systemd init systems were also horrible. The original idea of systemd which was a declarative and parallel init system was a good idea. The problem is that systemd has far out-grown being just an init, and it has been shown historically that it is far from "battle-tested engineering" (with the additional note that the maintainers are strongly against people allocating CVEs for their project).