It boils down to personal philosophy really. In the same way Microkernel vs Monolithic kernel is.
Sysv init and it's derivatives over the years relies on the 'Unix way' of little independent and autonomous scripts that are created by individual maintainers to help boot strap services using an init daemon. Init has no intelligence though and will go through the provided scripts first come first served. This can cause locks and timeouts as services try to start before other services have completed. Over the years there has been attempts to streamline this dependency hell but only to a limited effect. The init scripts became more and more complex as more a more distros started diverging in what core services the needed to start up.
Systemd took a different approach it made a smarter init daemon that could do more than just run custom scripts. It built a framework with dependency at it's core. It took a standardised configuration file which is very easy to understand and made maintainers fill out the bare minimum of what they needed to be there when they start up. An oft cited example is using the DependsOn flag which can be used to only bring up a webserver when networking has come up.
Where people got upset was Systemd did this so well that it was realised that other things could also benefit from having smart dependency aware daemons to process configuration files instead of scripts. This included the login subsystem, the networking subsystem, the filesystem subsystem even the peripheral subsystem. People got worried that systemd was taking on too many crucial roles and it was starting to become more than just an init daemon. They are right. But they also conveniently forget that it because the philosophy of how a smart dependency aware daemon was good for init like things it cannot be good for other things too.
Bottom line is some people don't like change and so they go off and do there own thing.
Working on trying to smarten up init scripts had been going on for decades. There was upstart monit eInit epoch etc. None of them really does what systemd can do which is why most distros and even component like Gnome choose to leverage it in some way.
There was an entertaining video based off a lawyer game that explained the various grievances between the two systems a while back. I can't seem to find it atm now. It certainly helped me understand what was at the heart of the differences.
But I am now convinced systemd is just a better way to do things and have created system units with ease. So much easier than cutting and pasting RC templates and trying to guess what may or may not be on a system I deploy to.