Seriously, have you even thought about this in any depth?
What's more safe and secure, many tens of thousands of lines of C running in PID0 with root privs, or interpreted scripts each running as root or with reduced privs in their own separate process?
It's obviously the latter.
Dangerous people like you must be discredited at all costs before young sysadmins believe your stupid sentence.
The Linux kernel proves you wrong, and obviously, the shell interpreter used to interpret your shell scripts proves you wrong too.
You're clearly not qualified to talk about this matter, and the obvious answer to your question is the opposite of the one you've given.
Shell scripts have always been unsecure, the countless workarounds that you can even find in the Linux kernel to try to mitigate the security nightmare that are shell scripts should be well understood by most sysadmins, or you're in for some surprises when you'll be a bit more seasoned.
The only compiled code is the shell interpreter, which is well tested and used all over the place with root privs already. And the shell scripts being run are trusted. Now, you can argue all the other points about the downsides of shell vs unit files. But as for security, this one is plain and obvious. All that C is just dying for a trivial buffer overflow or some other standard exploit to allow a full compromise of the system from some valid or even user-supplied untrusted input.
Oh man, you even contradict yourself, but you choose the path of nonsense anyway. Shell scripts most of the time (every time in distributions) need countless other binaries besides the shell interpreter, every single execution of which can be exploited, for example by changing the environment, even with race conditions, sth that is impossible to resolve with shell scripts if you need external ressources or even to write sth. Rootkits are very happy with initscripts actually, but they can't cope with systemd for now, if they ever can. Most of the dynamic state of Linux (disks, network, ...) need binaries anyway to be handled.
The only case when shell scripts work are with a well known customized static setup. Which breaks as soon as you change sth. Been there, done that.
Debian and its famous ifup/ifdown that never worked and will never work is another example: how many new sysadmins locked themselves out of their distant boxes, thinking that they could dynamically change their network configuration?
Yes, all that code is long overdue for a thorough audit; we're living on borrowed time as it is. How long to you think it will be until the first major exploit surfaces? Maybe then we'll have a rethink about the appalling design practices the systemd "geniuses" have foisted upon us. Having so much code running in the most critical and vulnerable part of the system is idiocy of the first order.
Systemd has already been audited and continues to be. Far more than sysvinit has ever been, and initscripts have never been audited.
A lot of initscripts are even full of very dangerious bugs or clearly unsecure, and can't be made secure because then they break and don't work anymore.
Most are impossible to secure. These initscripts need a sysadmin knowing their behaviour and constantly monitoring them to ensure they are actually running, as they just don't work.
No wonder every distro fled as fast as they could from initscripts.