I'm just going to assume you're not a troll, because your arguments are widespread, regardless.
Systemd is far more than an init system, it has 69 binaries !
It's actually far more than 69 binaries by now. That's a long outdated number. Nor did I ever imply systemd is just an init system. Where did you get that?
sysV init has no notion of plugin nor module system, but has a notion of script file
Where did I mention sysvinit? I wasn't talking about sysvinit. finit and initng are examples of plugin-based init systems.
Like systemd the init system
It would be very odd if an init system didn't have some way of configuring a service, don't you think? I don't see how this is meaningful at all - it's an absolute fundamental given.
But you can also plug yourself via the dbus api, which is far more powerful
Which, as I stated in a previous post, is nowhere near sufficient for the level of extensibility that I was referring to, such as that of Emacs. The D-Bus API is useful for writing layers of abstraction and remotely controlling and querying the daemon(s) in a more convenient way.
If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
And why the hell not?
There is no "not supposed to" here, it's only a) improperly designed architecture and b) lack of imagination that makes it so.
Yes, in systemd's case, such a thing is not meant to be done. The reason is because the init daemon is coupled with the process management and supervision framework, among other components. As other init designs have shown, a dynamic plugin architecture is practical and useful provided components are more loosely coupled.
I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
It's really funny that systemd proponents make such bland arguments deeply rooted in tradition. The same ones they decry a lot of opponents for making.