All the criticism of systemd is not strictly from a luddite perspective. There is a population that appreciates meaningful advances (Wayland, btrfs, even some facets of systemd), but doesn't like some of the compromises systemd has employed to achieve their goals. Getting stuck in a point of time before systemd is not a desirable result, and in fact systemd might be able to win over some detractors if they recognize criticism and make sensible technical solutions to those rather than continuing to say 'oh everyone loves it except some impossible to please luddites'. For example, journald could embrace native text logging with external binary metadata and deliver all the goodies they provide and quell all the (justified) bitching that human readable logging is a second class citizen in their model.
They may not be able to accommodate all the objections (e.g. the amount of complexity they *must* do in pid 1 to have guaranteed comprehensive service management without blindly applying namespace isolation everywhere that would make a system look even weirder/risk breaking some services), but they could come a long way.
The issue for many of us is that things are being implemented that go beyond what systems administrators can follow along without understanding how to be a more robust software developer (and even then, there's some loss of convenience in analyzing things compared to an interpreted language). Systemd design shifts focus on specialized tools that are better at their specific task, but less reusable in similar contexts. If I started with syslog and learned 'tail -f' will let me watch logs, then I have acquired knowledge that can be used the next time I encounter logging output. If I learn 'journalctl -f', then that knowledge does not transfer to the huge number of other applications that do logging. It's a small example of things that in aggregate pose a significant challenge.
An administrator faced with a 'classic' design won't know everything about the system, but can get far with 'set -x', 'find', and 'grep' because the configuration, logging, and much of the 'glue' code is in clear text, and communication between programs usually hits the filesystem in fairly specific ways. Now with things like systemd and dbus, 'invisible' things happen (well, overly generic communication channels and compiled code). When the kernel implements new awesome stuff, it frequently manifests in sysfs, which is nice and discoverable. Advanced functionality that adheres to the 'everything is a file' and generally presents and accepts simple utf-8/ascii data. Not everything in the kernel does that, sometimes it creates obscure devnodes with ioctls instead, but it's a common and good practice in kernel land.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components. While certain concepts can be specifically be done better (e.g. journald does better than windows event framework), the emergent behavior of Windows that becomes impossible to overcome by administrators isn't really due to those specific things.