One thing I am happy about though is I was looking through my notes and, at the moment, I think SysV init should shutdown (or reboot) about 4-6 seconds faster now than it did a year ago. (In other words, if you update from sysvinit-2.88 to sysvinit-2.93 your machine should reboot about 4-6 seconds faster.)
The reason for this minor speed boost isn't fancy optimizations or the work of elite hackers improving the code. Though we may get future speeds boosts that way too. What myself and a few others have found, looking through init's code, is there were a lot of places where the code simply went to sleep for a while.
Typically this was done during the shutdown process when init had to wait for something to happen. For example, init might ask processes to write their data to disk and then call sleep() for a second or two to give the write processes a chance to complete. This approach has two problems: 1. If the disk is really slow two seconds might not be enough. 2. If there is not much data to flush, two seconds might be far too long to wait.
A more precise solution is to call sync() on its own, without sleep(), which on Linux waits for buffers to be written to disk and then returns. So we end up waiting exactly the right amount of time. Doing the sleep() used to make sense in the very early days of Linux when a complete sync was not guaranteed using the sync() call, but for the past 20 years it has been safe to call sync() without sleep, so that is what we do now.
There are a few other places too where we were waiting for a process to finish, using the sleep() call, and then collecting its exiting information. Now we can just wait for the process to finish with a single call, again without calling sleep().
In the past year I think four of these cases have been found where we were waiting or in a loop, using a set time to wait for something to happen. These days there are function calls which will block until we get the information or action we need. As a result, init should be safer and more efficient.