I fail to understand the reasoning for choice as well.
I think I get this.
One example: I have a handful of shell and perl scripts that I use to manage virtual machine interdependencies at startup time - this vm needs to be listening on this port before I can think about starting this other vm, etc. and I express that in a JSON tree for configuration.
I've recently been noticing that the dependency "engine" is a bit buggy and also duplicates much of what systemd already provides (pre-dating it by some years), so I'm going to look at making it work with systemd instead and cutting out a bunch of the code. That also gets me pretty easy dependency tracking on various filesystem mounts, network status, etc., so it could be better than 'sleep 20' in some spots.
Now, if I wanted to offer that up to the community, somebody could choose to package that into Debian. Assuming my experiment works, systemd would be a hard requirement to use this particular system.
Somebody in the Debian community proposed that for this package to be accepted I would also have to [re]write another dependency engine and support that. I can't see doing that if the systemd approach works.
Does it make sense that people who don't want to run systemd (which is fine) also can't impose additional work on developers who do want to use systemd?