FWIW I modify the Debian init scripts too. rm -f /etc/rc?.d/K* is a pretty good start. The K* scripts are only needed when switching between runlevels, not when strictly booting up (when there is nothing to kill) and shutting down (when imminent termination is inevitable).
The problem in the BIND case isn't SysVInit or rc-style scripts, and it's not systemd's prerogative to solve. The problem is someone put BIND code on the critical path for rebooting. That is the mistake that needs to be corrected. Repeat for daemons we might find in a thousand other packages with code that is spuriously placed where it does not belong.
Server daemons that have special state-preserving needs can have scripts that try to bring them down with a non-blocking timeout (or systemd can do it itself). In practice, such servers don't get rebooted intentionally so the extra code executes only under unusual conditions where criteria for success are strict, or routine conditions (i.e. supervised upgrade of the software) where the criteria for success are greatly relaxed. That means the code doesn't get a lot of field testing, and its worst-case behavior only shows up in situations that are already full of unrelated surprises.
If I'm responsible for an application, then servers are just buildings for my application to live in. I rearrange the interior walls and fixtures of the building for the convenience of my application. If I need to reboot the server, it's because that building is on fire and I need a new one. I'll try to rescue my application state first--asynchronously, and with application-specific tools. When I have finished that, I'll tell the server to reboot. With that reboot request I implicitly guarantee there is no longer state on the server that I care about losing--my application is not running any more, or its state is so badly broken that I've given up. It would be convenient to umount filesystems and clean up state outside of my application if possible (in threads or processes separate from the rebooting thread due to the high risk of failure) but it is never necessary. The only necessary code in this situation is a hard reboot. Anything in the reboot critical path that isn't rebooting is a bug.
If I'm responsible for the server, then applications are cattle and I might want robot cowboys to organize them. This case is the same as the previous case, since my server would effectively be running a single customer-hosting application. systemd makes some sense as that application--although still not necessarily as PID 1, and certainly not as the sole owner of a variety of important kernel features. If a customer stopped paying for service or did something disruptive, I might intentionally destroy their process state with SIGKILL and cgroups. My customer agreement would have the phrase "terminated at any time" sprinkled liberally throughout the text so that nobody can claim to be surprised.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds