I’m all for alternatives, regardless of whether I’m gonna use them, but in my opinion, one of systemd’s big advantages is that you’re not relying on scripts for service management; scripts mix configuration with logic and this was a big reason why a lot of distributions switched to systemd in the first place. The init scripts (that they had to write themselves) were sometimes getting very large and complex in order to cover interdependencies (both to other services, but also to eventual mountpoints) and ordering.

Now, please don’t see this as a general criticism of this init system, firstly I’m not an expert on the subject, second I don’t believe there is the one and true design that covers all cases. My criticism is more towards the reporting about this when comparing to systemd.

There are comparisons that state that this isn’t the monolith systemd is. From the author’s own blog in comparison to runit:

nitro favors a monolithic approach, and keeps everything in a single process. This makes it also easier to install for containerization.

So if you’re really into that “do one thing and do it well” mantra, use something different. Note: personally, I think use what does the job best, and if you think nitro does a particular job better than systemd, go for it. I’d guess that it could be particularly suited better for the last three bullet points in the OP compared to systemd, but that would need to be tested in practice.

Anyhow, if you hate systemd or another piece of free software, go touch grass.