"I really wondered whether people would sympathize with me or just flame me."
It was not my intention to flame you. From your tone and sparse message, I assumed you were making yet another unfounded accusation about systemd; so many people on both sides (but mostly on the anti-systemd side) have been making ridiculous and untrue statements so often and for so long that I tend to just expect random made up nonsense to fly with reckless abandon. In your case, you have had a bad usability experience with systemd; and I can't deny your experience. I wasn't there.
That said, it is my understanding that rc.local continues to work fine on systems that choose to enable the compatibility layer. Fedora is my desktop and laptop OS of choice, and I don't think I did anything to make my rc.local files work. I don't use them for much, but I do have some custom hard disk spin down times and such setup on one of my machines, which continued to function after upgrading to a systemd-based version.
If your distro opted not to enable the compatibility layer by default, I suspect there's an easy way to do it yourself with a single command line or installation of a package.
Our servers all run CentOS and we've put a couple of new CentOS 7 systems online recently, and while we don't have any rc.local bits running on them, we do still have a few old style initscripts (in our products, embarrassingly enough, even though our bootup and shutdown module supports systemd and upstart, we still ship initscripts to start our own stuff), and they have continued to function correctly on CentOS 7.
In short, it has not been my experience that doing things the old way has been dramatically cut off for people who need to continue doing so for the time being. In my, admittedly limited, experience, I haven't noticed any difference except the "service" command now recommends systemctl when you run it.