I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
So you're saying Linux Torvalds has not enough creds so it's likely that he's talking through his hat, and you're making a fallacy by talking about Linux adoption which has nothing to do with this controversy. This controversy makes no sense for most Linux users who don't even understand what "init" is about.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
The C standard has moved since these decades, so I wouldn't say sth like that unless I was still heavily programming today.
And having problems with an init which is a very simple OS component, shows that moving to yet another UNIX environment would not be so easy for you.
Besides, Linux is not a Unix environment, it's Unix-like, but Linux is as close to Unix as systemd is close to sysvinit. It's precisely because systemd is made for Linux that it is not natively compatible with other Unix systems like the BSD.
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
You should do your homework in any case, but it doesn't seem like your job makes you involved in sysadmin problems, so it's understandable you clearly don't know what systemd is or does.
Which is a blessing, because that means you didn't modify initscripts which were all working perfectly for you, and so migrating to systemd will be a breeze.
And you will be able to continue not caring about your init.
What is so great about systemd has been explained time and time again, it's a very easy information to find, so people still asking these questions are obvious time wasters, aka trolls.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Your problem is right there! You know less than the people proficient with this matter, so you trusted them. And yet, now you say you know more than them and don't trust them anymore, even though it's obvious you don't know anything about what you're talking about, still asking where to find information. But no, you decided you are now more proficient than maintainers just because.
It's no wonder what you say don't make sense.
No, it's not. The job of an operating system is to KEEP them from becoming an interlocking mass, while letting them become an interacting system to only the extent appropriate. It isolates them in their own boxes, protects them from each other, and facilitates their access to resources and ONLY their LEGITIMATE interaction wherever appropriate and/or necessary. The job is to Keep It Simple while letting it work.
It's funny, because by your own definition, sysvinit was always a big failure at its task. Which is also the conclusion of everyone I know that actually used it and know how it works. Which is why people want to get rid of it for decades. And Linux was the best environment to do that because it's not Unix. And yet, Solaris did it before.
It's a good thing you came to the same conclusion as other proponents of systemd. Initscripts are nothing more than an interlocking mess of scripts with no knowledge of context or state. sysvinit didn't protect shell scripts from each other, it didn't even protect them from the environment.
systemd is actually doing all that. Actually, your comments about systemd and sysvinit are like you reversed these two words.