The "choice" people want is the ability to easily mix and match a patchwork quilt of software from different parties, each adding one tiny behavior. Wayland doesn't do that: it makes it so almost every behavior people want must be added to the compositor.
The magic is in finding what the right point in the abstraction is: what will be centralized and what will be decentralized. Both of your examples--systems and Wayland--made the same decision: the patchwork quilt of behaviors was complex for many users to get working, and even then often didn't work 100% always. It was also slow and a bit insecure (if you don't trust your software).
So, both systemd and Wayland took the same approach of pushing forward the boundary of abstraction and merging together most of the things people would have had to configure. This means that that one core component in the middle -- and sure: in Wayland you can have multiple implementations, and those can even share a library, but you can't MIX AND MATCH -- must do all of the things people want.
The reality is that no one wanted to maintain multiple X11 servers... but we also didn't want to! What we do want is to to be able to mix and match compositors and macro systems and window managers and all of the fun little behaviors that make a computer feel like it works for us, and now we can't, as we have to find and select a single giant ball of behaviors that happens to be close enough to what we wanted.
Theoretically, some day, someone could make a really advanced and capable display server for Wayland, one that will be extremely general and will have a number of protocols for how to extend its behavior. It will be the one display server to rule all display servers, and even ecosystems like Gnome and KDE could just interoperate with it, and we could get back the glorious ecosystem that people are killing...
...but that's effectively what X11 is, right now, and by the time you get that--with a ton of protocols that are old enough to be widely used--all of those behaviors will have aged and ossified and the code will be built by people who are gone in a language that isn't fun using conventions that are out of date, and some A-hole will point out that the stack is difficult to maintain and user's experience is variable and throw the entire thing out to start over :/.
Like, I dunno... I honestly do not understand how you are saying Wayland is doing the thing people wanted from systemd: the issue isn't that I wanted to be able to replace systemd, the issue is that I wanted systemd to not be a single giant C program because I really liked the patchwork of scripts and behaviors and alternative parts that were built up in the ecosystem.
And again: everything tends to end up with some central thing in the design somewhere... but you have to make that thing be so boring that no one has any interest in innovating on it, and X11 was that: while I do think we should have multiple implementations for robustness, we would expect every one of those implementations to work as close as possible to 100% identically.