Wayland and systemd are two topics that I credit with showing me that I shouldn't give too much weight to the consensus on Hacker News and Reddit. Things turned out opposite to the prevailing sentiment at the time.
systemd faced an enormous torrent of criticism for replacing the simple sysvinit with something more complex. Yet, sysvinit was only simple if you focus on the init program only instead of taking a systemic view. Under sysvinit, if you wanted to turn a regular command-line program into a daemon, you had to code a whole dance of closing file descriptors, sanitizing environment variables, forking, calling setsid, forking again, resetting the umask, and so on [0]. You had to make sure that all code writing to the standard output and error streams was changed to use the syslog. You also had to manage a pidfile in a way that was free of race conditions. People would write the same logic over, and over, and over again in different projects and programming languages.
On the admin side, a server system with a sophisticated configuration that involved starting daemons when a connection arrives, automatic restarting, e-mailing on error, and so on, could easily turn into a complicated maze of interacting programs and shell scripts. To get the full picture of how a daemon is actually managed, you would need to check many config files with completely different syntaxes.
systemd has greatly reduced this pointless duplication of effort by centralizing the complexity into a single, well reviewed set of implementations. Now, you can take a small program that runs in the terminal and prints log messages to stdout and, with a single INI-like file of a dozen lines, turn it into a daemon whose process supervision is better than anything you could implement yourself. The ease of configuration encourages you to add features such as automatic restarts, resource limits, or dynamic users, which you probably wouldn't have done on sysvinit because it was a pain in the ass.
Wayland, until recently, almost universally praised, but it does the opposite. In order to keep the protocol pristine, it just pushes complexity onto everyone else and ends up making the situation terrible from a systemic perspective. Wayland can push video from a regular program (client) to a privileged one (compositor), but when asked about pushing video the other way to record the screen, they went "not my problem" so pipewire has to handle it. There is no longer even a set of standard command-line utilities you can expect everywhere. On X11, you can type a setxkbmap command to tweak your keyboard layout at runtime regardless of the desktop environment. You can get information about the connected monitors with an xrandr command. In Wayland, every compositor has its own way of handling these, and sometimes you can't even change a keyboard setting without restarting the compositor. What a regression and a blow to the community of tinkerers who like to share small utility scripts with one another.
These are just two examples, but I don't think that Wayland's approach of targeting specific use cases, instead of providing a set of general tools, can ever work well when combined with its bureaucratic approval process. It took years of asking before Wayland devs decided that maybe the user should be able to disable VSync after all. It also took years to backtrack from the bizarre choice of making the UI scale integer only instead of just exposing the real fraction set by the user.
[0] For details, see https://www.freedesktop.org/software/systemd/man/latest/daem...