Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system
systemd is not init system, its and umbrella project for various core system components, which includes an init system.
> There is absolutely no reason to tie your new sudo replacement to systemd
well, in this case there is good reason to have it interact with service manager in general
> But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID [...] Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client
strictly speaking it's not 100% coupled to systemd specifically, it most likely uses systemds d-bus API, which is part of their "portable and stable" APIs and as such could be implemented by other service managers https://systemd.io/PORTABILITY_AND_STABILITY/
> This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason
The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers. The minimal systemd build has only init, journald, and udev, which is not exactly sprawling huge. All the rest of the projects are fully optional, and I believe quite many of them can actually work without systemd-init