The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle?
systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window.
The systemd people should be made to work building and maintaining a real-life backend environment for a while.
I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability.
One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-: