What you can expect when switching from a system management tool written for Linux to an init tool targetting the least common denominator of general Unix functionality?

Less functionality, less security, less information about the state the system is in, less reliable switching between states and a whole lot less of linux kernel features exposed to your use in convenient ways.

It's not as if systemd was started to be complicated, the world got complicated. E.g. we used to just create all the device nodes in /dev statically during system installation. Then USB became a thing and supported so many different kinds of devices with thousands of potential ports to connect them to. They would not fit into the device node namespace! So we needed to make device nodes dynamic, which is also convenient.You do not have lots of device nodes that do not exist on your system and you no longer need to change system configuration when you plug your mouse into another port of your system.

Filesystems, security (often linux specific) features, everything is easy more complex (and more dynamic) today than it was when sysv init was a thing. That simple stuff was great when you had to power off your machine to change its available devices. It is less cool when you plug an USB-C cable into your laptop and want to use all the stuff that is now suddenly available.

You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

So I seriously doubt you loose out when using AGPL or GPL.

Portability matters.

In general: Yes. In the specific case of an init system for a specific OS: Not so much.

This is nicely demonstrated by none of the non-Linux OSes embracing any of the options you listed. They all want something that plays to the strength of their specific systems over some generic Unix thing.

If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.

It is the best approach we have on anything running a Linux kernel.

systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.

It is also easy to have really simple code that does nothing interesting whatsoever. And for something that does not do much at all, the fork-dance that e.g. s6 does is pretty complex.

Maintainability also does not seem to be a big issue for systemd at this point in time either.

The smaller attack surface is relative as well: systemd-the-init is a bit bigger than the ones you list. But the difference is not as big as you make it sound and an init system does not do many interesting things that can get attacked by either.

On the other hand systemd can seriously lock down any service it starts (and does so out of the box for anything from the systemd project and many upstream projects that ship locked down systemd unit files). The init systems you listed do can not do that directly and either need helpers (which increases their attack surface again) or just do not bother. Considering that a init system starts way more lines of code that do more security critical things than an init system: I think this lockdown does lead to a smaller attack surface of the system overall.

systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay;

Somebody has to invest work to make things convenient and easy to use. You either run with what everybody else uses and share the effort or you do not and do the work all by yourself.

This is in no way systemd specific.