It's not that your system fills up with them from your side. It's that the old approach of not-very-synchronised shell scripts is very fragile and sometimes arrived to via trial and error. And many services carry their own custom implementation of those.

For example mysqld_safe is there pretty much to handle things that systemd can do, but initd can't. Some other services have custom wait-logic to make sure dependencies are ready, which is covered by service readiness notification in systemd (see just yesterday https://news.ycombinator.com/item?id=25845143). Many services do custom pidfile handling (see the fun implementation in openssh init file - your pidfile path better not have `=` in it) just because initd has no idea of services.

Basically every service I've seen which has more than a single line in start and stop functions in broken is at least one subtle way. (and close to every single status function - no, existence of the pidfile and that pid running an undefined process is not the same as service functioning) Systemd provides 99% of what those init scripts try to achieve as simple configuration and if something's missing you can still fall back to executing a script instead.

It is a straw man that people use to try to try to make systemd seem like a solution, the only issue is that the problem never actually existed, just like people who try to argue that "x is dying or not attracting enough new users" in order to try to present a change they want to make as some how "solving" the problem of users leaving (e.g. "we should switch development to github"). When you look at the numbers and look at the existing systems, the stories are a complete fabrication to try to prop up a fallacious argument or process, tool, or project that is usually worse than what is really out there, not what its proponents claim is out there.