Your implication is that sysvinit was designed for speed. I can't seem to find much evidence for that.
In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contrast to the BSDs), meant it was slow.
IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier.
The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.
I think it was originally designed for speed (or at least for simplicity) because it only dealt with a handful of use cases that worked well. Granted, they were the more general use cases, but writing a dependency solver into the init system in 1980 would have negatively impacted speed to an unacceptable degree. Applications back then weren't modular enough for it to make a ton of sense anyway. So they traded flexibility for deterministic execution that was "fast enough". That's not a tradeoff you have to make anymore; CPUs are fast enough now that you can do all the thread syncing you need without worrying about the overhead too much.
But flexibility and modularity is more important now than maintaining compatibility with decades old init scripts. Some of those modules may need low level system access for a variety of good reasons. The kneejerk reaction is to apply network server use cases to every Linux feature, but Linux is a whole lot more than a network server these days.
In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contrast to the BSDs), meant it was slow.
IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier.
The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.