I hope you're being deeply ironic.
It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.
sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.
As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
systemd might be more convenient from the point of view of an end user. And unit files might seem superficially simpler than a script.
But systemd is not simpler. It provides significantly more complexity, while also providing a lot of features.
systemd is also not more reliable. The previous system, even with LSB dependencies, was usually run in a linear mode with scripts run in a strict sequence. System boot and service startup was deterministic.
If you read the part of the linked article about the sheer quantity and complexity of the internal state managed by systemd, and how it is not deterministic, or even fully understandable even by its authors due to the combinatorial complexity of all the options and how the same settings work differently in different contexts, I'm afraid that I can't do anything further to convince you about the significant design problems it has which directly impact its reliability. Never had it hang irrecoverably at boot, for no discernible reason?
There is a reason people such as myself are appalled by its design. It doesn't even have a comprehensive specification for such a critical piece of functionality. It's defined solely by a single implementation.
The systemd state is a massive hairball. It's effectively a black box, and understanding why the system exhibits certain behaviours is difficult.
The sysvinit state consists of a current runlevel and the state associated with inittab tasks, which is pretty trivial. It doesn't attempt to maintain a mirror image of the state of the whole system, which is largely a constructed fiction.
Proof? sysvinit's surface is anything you can call. It's internal state is everything on the system.
Systemd's surface is the (well documented) commands in the systemd unit files. Each unit is pretty much independent, the dependencies are specified and well defined. Their internal state can be examined and explored.
For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it).
The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.
But I've been using systemd for a long time (since Fedora 21). Maybe we're all coloured by not only when we first encountered it but by our distro and how simple they make things? FWIW I'm using Debian and Arch these days and still struggle to "enjoy" systemd, but it definitely functions better on my arch machine.
I don't understand how this is an horrible thing. Thanks to it you can do stuff as
systemd-analyze dot > /tmp/foo.dot ; xdot /tmp/foo.dot
The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic.
Read: A confusing mess of different daemons, scripts, and configuration files, which neither worked together elegantly, were simple to configure, nor were easy to debug. Before systemd I would avoid writing custom daemon configurations at all costs because when I did I would need to learn how this version of this distro did it, fiddle with the byzantine mess of scripts, and inevitibly debug multiple subtle issues, now it's basically trivial to get a new daemon running, and I extremely rarely need to debug issues (And I have had to track down systemd bugs due to obscure use cases like one systemd unit modifying other systemd unit configs at the same time another systemd unit with multiple execstart lines is running).