Yes, "init" is a bit of a misnomer, given that it also handles shutdown/runlevel transitions. I see the big difference here as being between the people who think that the job of the OS is to provide a simple base for executing user-defined scripts, and well, everyone else. I think that an appropriate analogy would be handcrafted goods versus mass production. Linux has been transformed into a wide variety of products at various times, and while I don't think the init scripts played a very large role in any of that, the idea that the OS is what you choose to turn it into does have strong credence in this community.
The other side of the debate, I think, are the people who feel like a collection of init scripts should be refactored somehow, and mostly this seems to involve rewriting things in C, adding dependency annotations to init files, and implementing support for cgroups. At least that's what OpenRC has been doing. Systemd unit files go a step further, but it's a good step in my opinion. Anything that any two scripts do should be refactored into a common method or library, and hopefully that process leaves very little for the init script or unit file to do.
It doesn't matter to me personally whether this stuff gets done in Bash or C; I can't really maintain either. I could probably write a unit file if I had to. I understand there are lots of people who have put lots of time into writing Bash scripts. Some sysadmins may even think that their job is to write scripts. These people should continue to write all the scripts that they want, because Linux is all about that, but maybe they should also let other people write a decent plumbing layer for Linux, because modern OSes are all about that.