Yeah, I realize that isn't quite apples-to-apples, but still, systemd is a ridiculous beast. We used to mock Windows for this sort of thing, and now we've become them.
I get that not all people want to use the whole systemd family of tools, but comparing line counts like this is ridiculous and unproductive.
And it's also a lot considering that most (?) of those lines of source are compiled into a single inscrutable binary. One of the great boons of init.d shell scripts is that you can just look at them when something is going wrong, and quickly realize that they have a bug.
If something's wrong with a unit file (and/or systemd itself) it can be extremely difficult to debug. The unit file for a reasonably common piece of software (ganglia) is broken, and apparently still is after years. I've no real idea of how to debug this, and certainly don't have time to fuck with it. At least in this regard, systemd sucks.
The init binary of systemd itself is ~70k if my math is correct & still has a much richer feature set.
I don't know what init.d shell scripts you've been looking at but my experience has not been as pleasant. Also, if you as an end user are looking at init scripts there's something massively wrong with the init system. Never heard of Ganglia but they seem to be on github. Have you filed a ticket with them? Have you messaged them on whatever forum/IRC the devs hang out on with your issue?
Yeah, I'm not crazy about the various init scripts that have been produced over the years. But at least when they're broken, I can usually just glance at them and see that. With systemd, mostly one just gives up.
Write a better one.
"Be the change that you wish to see in the world."- Gandhi (maybe)
Hey look at that. The critique that systemd has a log daemon (why does init need a log daemon?) doesn't really fly. Also runit doesn't have the ability as I understand it to properly specify dependencies between components falling back to the crap of runlevels. You won't see it as a user. You see it consistently & repeatedly as an OS developer/maintainer & through slow boot times. Then you have upstart which has some dependency & parallelization effort.
The fundamental architectural flip that systemd takes is, as I understand it, that each service/process starts as needed & just blocks on I/O letting the kernel manage parallelism implicitly through synchronization mechanisms that are robust & easy to maintain rather than manual config files. There's a lot of complexity here. There's name discovery & registration so that when you have a dependency on you, you automatically start whenever a dependency tries to access you. The logging mechanism is because you want to make sure that logging is robust & functional. The binary mechanism is great because it drastically shrinks the size of the log files, reduces the overhead (printf format strings are expensive), & makes it easier to write tools to process them.
I'm not sure about the DNS & other binaries but I'm sure there are similar intrinsic architectural problems those tools are solving. Again, none of these are necessarily ones you see as an end user directly. You see it indirectly because a lot of diffuse time is spent finding/fixing bugs due that architecture (yes there are still bugs but they're of a different flavor, and, hopefully, bugs you'd have in either system.
BTW when I last looked at systemd, superficially it looked very very similar to launchctl in terms of design with many of the same benefits.