You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.
While there is a grain of truth, the rules are a bit more straightforward in SYSV. SYSV was created by people that were largely starting out and did KISS out of necessity. So one needed only to understand some relatively basic bourne shell and you could figure it out from there as needed, even if you didn't know it. In his example, environment variable fell out of the sky. In init script, you know it had to be set *SOMEWHERE* from that script. It sourced another file, bingo, there it is in plain text. There are some things in SYSV that are a little weird (runlevels being arbitrary numbers, but there's a handful of them and inittab was a relatively short file), but generally it was quite discoverable given relatively simplistic understand of shell scripting. In systemd, if the config files pan out right, then they are simpler than the SYSV scripts. When things go wrong beyond what the author had intended, sysadmin is less likely able to figure out what the developer did wrong and correct. This I think is the fundamental breaking point. systemd adds some features that I can't readily imagine being acheivable from shell scripts, but it's harder for a layman to dig into something that went wrong. This means software vendors can deliver more service automation and such more easily under something like systemd, so many software developers appreciate it. Sysadmins on the other hand cede the ability to be able to look under the hood themselves. It's a tricky walk.
more traditional systems have started to similarly fragment things, what with things like udev rules
udev is actually another beast that could use a lot of improvement, alongside DBUS. dbus, systemd and udev start straying from 'everything is a file' and start creating invisible constructs in a namespace that isn't really explorable. 'Everything is a file' sentiment has been lost. What people forget is that everything is a file really just means a pretty straightforward yet capable organizationed model that a client can explore. It's like RESTful in webservices are supposed to be (though that facet is also frequently unusable in some web frameworks, many do get it right).