"Honestly - you can do this conveniently without systemd."
You can do this *more* conveniently with systemd *and* it is a compile time option. I am already using it and it well worth the integration as far as I am concerned.
"We have yet to see what Red Hat does - as I already mentioned here, we have 2-3 years until the next major RHEL release. It's hard to speculate."
No speculation necessary. Look at the entire history of major Fedora features sponsored by Red Hat and name one which hasn't landed up in the subsequent RHEL. Hint: There isn't one. I can wager a bit that it will land up EL 7 or even earlier.
"The whole point is that to me (and a lot of Linux ops folks out there) systemd will ultimately make it harder, not easier to manage servers"
This seems to be just handwaving. Who are those unnamed Linux ops out there and how is it making it harder for them, exactly?
"The "ad-hoc" (site-specific) and distribution-specific scripts are easy to read"
If you can read say a 100 lines (do remember to count all the include files) better than say 11 lines, sure.
"if you need to change something deep in the startup/shutdown process, you don't have to modify systemd or daemon code and recompile."
Fedora 15 uses systemd by default and noone has presented a single case where it is required to recompile anything. You are just making things up here.
"Plus you need explicit support from the daemons if you want them to be fully compatible with systemd"
No. A few daemons like rsyslog needs a tiny patch and they are all upstream already. Rest of them are already full compatible. systemd is compatible with sysvinit scripts and hence if third party software doesn't get modified, no big deal. Yeah, you might end up with some shell scripts in some cases. So what? This makes the whole contention that systemd is eliminating your precious shell scripts pretty pointless. You can't have it both ways.