One example that neither camp does well is 'status'. Systemd is too verbose, but at least always the same standard output. Sysv init is whatever random noise the author decides to put out. Sometimes it's multiline. Sometimes it's no line, but an exit code. Sometimes it has colour. Sometimes it doesn't tell you whether it's running or not, but just outputs the service name. Sometimes you just have to be familiar enough with running the service such that you have what the status lines actually mean already in your head.
> It doesn't do anything but run a program with an argument.
It also needs to find that program again in order to provide status on it, stop it, and if the application has support, reload it. Very few init scripts are fire-and-forget startup scripts.
You can't say the same of systemd. It has to be whatever systemd has compiled in. (Which, by default, is terse status, followed possibly by journal data, or just system status if no units are available) Sysctl status also loads a unit at run time, and then may unload it afterward, meaning it is not useful to see if a unit was already loaded. It also uses a UTF colored dot, combined with different lines that can be interpreted different ways. In other words: it is a complex arrangement of information. And for machine output, you need the 'show' command, and more options.
With sysv, you ask it for status and it tells you if it's running, if the script supports status. Clearly a complicated mess.
Your last comments don't make sense. Sysv init scripts don't have to "find" a program any more than any other method of executing a program. And all init scripts I can think of are fire-and-forget, as much as systemd or any other init program is. The only thing they don't do is continue to try the same operation over time or wait around for a dependency, if that's what you meant (which Sysv scripts aren't really supposed to do, but inittab supports it anyway)
I'll do you one better on your first comment: ALL Sysv init scripts are a different "structure" internally. Even in the way they are used! The reason is, they're just scripts. Outside of inittab, there is no real standard for how they work, so each system makes them work however they wish. They can write them so they're all the same, or all different, and make them called the same or different, and give them different features, or no features. This is why some people love Sysv - it is totally flexible. You can make it do anything you want, and all you need to know is csh.
With other apps (not just systemd, but lots of things) complicated custom domain-specific languages are invented to do little things, like change configuration files' permissions, or send a file somewhere. Csh/Bash allows you to do the same, except it's a lingua franca that is compatible with every Unix-like operating system. It's interpreted, it's flexible, it's portable, it's backwards compatible, it's composable, it's extendable.... I mean, this is really an amazing thing that no other language or tool can claim (other than web browsers). Any problem you have with Sysv you can fix it within Sysv, without requiring compiling code, or even rebooting. I know i'm beating a dead horse here, but I just can't see how anyone would want to throw all this amazing power away or see it as limiting.
If you wanted, you could write a systemd clone in bash, and make service/unit files out of bash. I don't know why nobody has done this yet, but probably because it would be self-defeating.
On Slack, the init scripts range from 6 lines (rc.font) to 445 lines (rc.S). Mean: 105, Median: 64, Mode: 56, 36, 48. BSD probably has even less complicated init scripts.
Your system might have more complicated init scripts, but it doesn't need them to be complicated. I suggest you direct your ire at your distribution, not init. (Most distributions totally misuse init and try to make it do things it was not intended for)