If you want, you _can_ still use systemd as if it was just a SysV implementation and have scripts in /etc/initd (or was it /etc/rc.d or /etc/init.d/rc.d on your distro?). I actually still use them (or rather the rc<daemonname> symlinks in /usr/sbin to them) out of habit. But most of them are nice and redirect to systemd to do what I mean.
"You can implement a daemon which would launch scripts from /etc/init.d/rcS.N and use /etc/inittab, you can introduce special functions in the scripts to support reliable service launch and PID capture, you can still have this daemon to listen for callbacks from the services to indicate succesful startup, catch service startup output in a structured log, etc."
In other words, one could create new infrastructure to support those features and rewrite every single init script to use it. Administrtors would have to learn a lot again about what new magical commands one would have to use to start a daemon.
But why not use this chance to go a little further and make another leap in usability and features? I still remember the WTF look on my dad's face, when I showed him how to fix the ordering of the init scripts on his server by editing some magical comments in bash scripts.
"You can even provide OPTIONAL ability for parallel startup for those who want it, while keeping the traditional startup sequence by default."
I have not had a purely sequential startup on my systems for a decade, since SUSE's init already started init scripts with the same number in parallel. So systemd does not even deviate here from SysV. It just fixes the mentioned WTF problems.