look all u have to do to answer the question is name things sysvinit does better than openrc s6 dinit and runit
The big upside is that sysvinit (and I'm throwing in the *BSD rc.d paradigm too) is thoroughly auditable and allows the user in question maximum control. OpenRC is elegant, but it wasn't designed as an init system first and foremost; it was originally a set of abstractions atop sysvinit that
eventually became an init system via OpenRC-init. Even so, it's not like we have an LFS book that covers building an LFS system with OpenRC-init, let alone dinit, s6, or runit.
All the other alternatives to sysvinit have merit, they're capable of parallelisation, they're hotplug-capable, they can manage sockets better, orphaned process handling exists, these are all things that sysvinit can't do that systemd's technically capable of doing, but without systemd's aggressive scope creep. That's good insofar as providing meaningful alternatives to systemd, but that doesn't automatically collapse sysvinit's appeal. Judicious users who prefer sysvinit (or indeed, the *BSD rc.d paradigm) value sequencing their daemons and user services by hand, entirely in plaintext.
In sysvinit and rc.d paradigms, if something gets bork'd, it's entirely a user error with respect to configuration. All the troubleshooting means are plaintext and accessible, so if you made an error sequencing your daemons, your services, or what have you, it's just a matter of rearranging them and rebooting. The good thing about sysvinit is that it's decades old and tons of documentation already exists for it. If you bork your exotic s6 or dinit system, you're basically limited to the troubleshooting PDFs that Artix ships with. They're good resources, to be sure, but they still pale in comparison to the sheer volume of historical support sysvinit had, and the obscure hacks and workarounds people used to get their shit up and running.
sysvinit and rc.d also encourage more "traditional" Unix habits and practices. Since your initscripts are basically shell scripts unto themselves, you're able to better leverage crontab for task automation. That's not even getting into how sysvinit and rc.d are
much closer to being POSIX-compliant. While Linux is notoriously poor with long-term API/ABI compatibility, rendering POSIX-compliance more theoretical than anything else (even before systemd actively broke POSIX assumptions), there's still a huge body of software spanning decades that was built specifically with a vaguely POSIX-compliant userland in mind.
runit, upstart, OpenRC, dinit, s6, all these init systems exist to solve the biggest problems with sysvinit, but then they open the broader question of "am I able to build software from source with minimal fuss on this platform?" OpenRC gets a pass because it's the most "mature" of the alternative init frameworks and it's stewarded by the Gentoo project, but it's far from frictionless in this respect. It's worse in the case of dinit, s6, and runit. I mean, most people run binary packages with those init frameworks under Artix or Devuan anyway, but still: if I can't make an LFS and BLFS build out of a dinit, s6, runit, or even an OpenRC system, something's terribly wrong with the picture here.
