I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.

...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.

You're confusing sysvinit with sysv-rc.

You do realize that there are only a few binaries?

Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.

The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.

With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.

logind handles logins

Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.

it handles sockets for socket activation

Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post...

It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.

Mount points and swaps are just small unit wrappers around the mount and swapon/swapoff binaries. It's oversold. Once again, path-based activation is a buzzword for reacting to file system changes, which you can do by leveraging inotify(7) or fanotify(7) independently.

There's pretty powerful cron replacements these days that can take the place of timer units.

I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events.

Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.) It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.

How do you define a "dynamic event"?

Have a look at the dependency list here...

Your list is for systemd-204, which is heavily outdated. systemd moves really fast.

There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.

Too bad it's apparent that you didn't do much of it yourself.