At this point I don't really want to touch the systemd argument with a barge pole anymore, but I think it's worth saying that I'm a lot more comfortable with the sysvinit script.
After a lot of years of maintaining and editing and writing configuration files for more Linux daemons and applications than I can remember, my least favorite are the ones like the top example, that have a pile of predicates and values. They require careful reading of documentation to look for any traps and gotchas (the documentation always has a fine print section buried deep within it somewhere that says, "oh, by the way, you can't foo with a bar setting because that will cause a baz to foom"). You have to either memorize a bunch of variables specific to a single application, for a ton of applications, or you have to spend time referencing documentation (and re-reading it for those gotchas) every time you open the config file. There's also the nuisance of new predicates in later versions, hidden and undocumented predicates, and on and on.
It's just a pain in the ass. Really, as much as I love Postfix otherwise, it is the poster child for why this approach sucks monkey. Here's the documentation for Postfix: http://www.postfix.org/documentation.html ... let me know when you've read and understood all of it. :-)
But the sysvinit file on the other hand is easy. It looks uglier, but only to people that aren't accustomed to shell scripts. I can take one look at it and know what most of it does, because all other shell scripts do similar things.
And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
The default response here is usually, "well, we'll just keep the configuration file simple then." But that never happens. I would bet a donut that, years and years ago, some Postfix developer said, "the sendmail configuration system sucks, we'll do our own, and we'll just make sure it stays simple."
But software never gets simpler. It's a steadfast law, a more universal rule of reality than the arrow of time. Software only moves in one direction, and that's towards more complexity. The safe bet is that ten years from now, those systemd configuration predicates will have exploded 10-fold, with lots of hairy edge cases and gotchas and hidden or poorly documented interactions, because that's what always happens. A shell script on the other hand will still be editable; the Apache sysvinit script you posted doesn't do anything that a shell script couldn't do 15 years ago.
I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.