There is quite a few, for starters the lack of dependencies, processes are just loaded in a pre-defined order and so if you have one daemon reliant on another service but the first service fails, sysvinit will just continue to load the latter service. This means having to manually detect if the previous daemon is running and terminating self or worse, letting the dependent service load when perhaps it should remain down.
The above plays into the fact that sysvinit really has no idea what state the processes it starts are running in.
Single threaded initialization, it's mainly a speed thing here so it's opinionated but in an enterprise environment this is actually meaningful. Longer boots is increased downtime for any reboot, like kernel updates for example. It's also not great when you have a customer on the phone shooting for their site to be brought back up right now, you check sysvinit and see it timing out on some process to later find out said process was trying to run a rdns lookup request that never got answered and so just sat their for 5 minutes holding up the entire boot process.
But the biggest issue, is generally other System Administrators who put together kludges into init scripts, so you end out with bespoke servers using band aid solutions that then later break for various reasons (i.e. package update replacing said script). This is often due to the quality of the sys admin but in a real enterprise environment, you shouldn't be running bespoke and patchy server configurations/scripts.
Biting the hand that feeds IT
