The complaint is that the process at PID 1 should be simple.
That's just passing the buck. What you don't do in PID 1, needs to be done by PID 2 or 3 or 4...
One has to understand that system start up is a complex task. Systemd, sysvinit, launchd, and what-not are just a matter of optics, no matter which one you choose, you are only changing how you look at the problem, you aren't making the problem any easier. That's the important thing to remember, that all of these inits are just different views on how to solve the problem. No matter how many times you break the process up (into PID 4 through 380), it's still a complex task that needs to get done.
That said, sysvinit comes with the idea that you're going to have a lot of people looking inward at what's been done historically, they're going to make really useful tools, and the expectation is that those that follow will use those tools. That's nice and there is a real benefit for that, but that's not what vendors are going after, that's not what third-parties want, and that's not what end-consumers want. The only people that sysvinit caters to any more is developers and neck-breads. Vendors are going to write their own tools for start up. Third-parties are going to package up the process into something that can be simply delivered to the customer. Standard end-users just don't give a shit so long as the screen comes up. Heck, even server admins won't really care so long as management can still log in. There just isn't clientele for the old way. That's not to say that the old way isn't useful, but honestly you are asking a bunch of Pepsi drinkers to switch over to Coke for just the sake of "it is easier to make."
SystemD puts all the cards closer together, this allows smaller teams to do useful stuff, and let's face it, the number of people writing kernel, sub-system, and start up code is only going to keep dropping. The hotness is much, much higher up. Vendors like systemd because it works better than script->call program in their deployment cycle. Now they can use systemd reporting to bubble back up into the UI as oppose to writing to some arcane log file. No one can defend the old log files, they seriously were so confusing that there are companies that you can hire and tools that you can buy that can turn your log file into something easier to read. That's just indefensible. I'm not saying that systemd is some magical power that's turned a turd into gold (starting up a system is still a pain in the ass), but it serves a wider group that more than likely (as all the neck-beards die off from old age) will be maintaining this whole thing in the longer term and simplifies something that has gone from, "it was good and easy" to "holy crap! The log file is 23MB!!" Back when we were starting up an FTP server and that's about it, it was great, but now that every sub-system from the kernel feels a need to write to the log on top of everything else that you vendor starts up, it's just a flipping mess.
It's important to remember the Unix way, but systems have gotten so complex we just don't do it that way in reality anymore.