I do, it's "if you run a big mainstream distro like Fedora or Debian, let your users swap out init systems". I know there have been debates on this, and I know the general consensus is "it's not worth the trouble / it's not as simple as just swapping out something like systemd". My counter arguments are: there are distros that are doing it, so it doesn't seem like it's that bad after all, and when dealing with something as important as PID 1 (or your libc, or your filesystem) we should be conservative and let users swap things back when making a huge change.
The other thing that jumps out at me is just that this hypothetical is mostly kicking the can down the road. If Fedora suddenly decided to support multiple init systems I think it's hard to envision a future where the happy path wouldn't remain systemd; it's what the core folks think is best, otherwise they wouldn't use it now, and even with additional support the lion's share of attention would go to that happy path. To that end I think that any sort of init choice in those distros just becomes "so we'll support it for now, but the set of third party stuff that supports it is going to continue to shrink, so I hope you have an off-ramp in the future."
Between these two issues it seems like separate distros that have a firm commitment to not-systemd end up being necessary anyway and an ecosystem of not-systemd stuff will need to compete for value on those merits. What am I missing?
I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowledgeable heads. I get the drive for very rugged underpinnings, and I'm on board with that; in things that aren't C++ I frequently am the one with the scalpels making criticisms similar to yours, so that totally resonates with me. I am not, however, convinced that any of the alternatives that currently exist are materially better, so I kinda shrug a bit? Further, it seems to me that the generally modular nature of systemd (regardless of how coupled one believes those separate modules to be) suggests that a determined programmer could probably build a drop-in replacement--Rust? Where's my Rust Evangelization Strike Force?--that plays nicely with it and grows to replace poor and soft design.
The social aspect you bring up is, to me, the most compelling argument against systemd (because monocultures aren't great in general, etc.--I think most people agree on that). Thing is, though, I think that that bottom-up consensus model was doomed from the start. I don't think it was ever going to be tenable as soon as there's any money in it. Red Hat wants consistency, their stuff is going to have consistency, you can use it or go off-roading.
I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death." Which is a deeply unsatisfying and impractical answer. And to be clear, people who feel strongly about it should do that. I'm not being snarky when I say that. I'm a pragmatist--if it's better, I'll use it, too, and submit patches if needed and when I'm capable. ;)