> In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc).
Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.
Assuming that your comment is in good faith, that comparison doesn't work in the way I think you're trying to make it work.
systemd operates (when used normally) at a higher level of abstraction than a bucket-of-scripts/sysvinit. Especially because systemd units are declarative, this higher level of abstraction affords you (the sysadmin) the ability to more precisely specify the behavior you want. However, you can of course run scripts from systemd, so you've got whatever escape hatches you like. My question was asking if there was anything in sysvinit that those escape hatches didn't cover adequately.
Assembly, on the other hand, operates at a far lower level of abstraction. Inappropriately low, in fact. Because of this, you actually have less practical ability to specify the precise behaviors you want. For example, you'd be hard-pressed to use assembly to start a webserver after the network is up but before some other piece of software that depends on the webserver.
Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.