As an enterprise level sysadmin, there's a couple of things in systemd that I think are pretty darn cool, and there's a couple of things I'm not looking forward to.
On the cool side, I rather like that systemd can reliably detect daemon termination and restart it, as well as some of the cgroup daemon isolation stuff. This is quite welcome.
On the concern side, I worry about the extra time it's going to take to debug issues in large chunks of compiled code v. script, the extra dependencies (e.g. on dbus), and I am annoyed at having to learn yet one more subsystem.
The cool stuff is pretty self explanatory, but allow me to explain my concerns.
Extra debugging effort: I recently (in the last two weeks) had to debug a LDAP client performance issue related to over large LDAP queries.
In one case, I found the bug in a set of perl scripts used as service monitors for our veritas clusters. I was able to find the offending code, modify it in place and test the fix in about 2 hours.
In another case, the issue occurred in a bit of compiled code using LDAP (sudo in this case), I had to download a large bit of code, spend a good amount of time reading it, spin up a compiler / development environment, *then* make changes and test 'em. Note that this had the advantage, since it's a pure user space program, that I could test it without e.g. system reboots, and the codebase was smaller than systemd's. Total time, a day and a half.
It'd be even slower for systemd, 'cause the codebase is notably larger, and it's significantly more tied into the system; I'm not sure it could be tested without rebooting.
Extra dependencies: as a good sysadmin, I try to follow the principle of running only the minimum stuff required on a server. For instance, my web servers have only 26 processes on 'em. More stuff running == more stuff to go wrong, and more attack surfaces. In general, I prefer to not do so. From what I can see, systemd requires at least d-bus, and maybe more besides.
Yet one more subsystem: the thing here is simply that sysV init isn't going to go away. It's not like our many hundreds of customers running on rhel5 are going to magically migrate to rhel7 the moment it hits. So I'm going to have to continue to know sysV init, and at least a bit of upstart for personal use, then add systemd knowledge on top of that.
For instance, when my boss tells me to install a new monitoring agent, and I write a puppet recipe go install and configure the service, and it doesn't work, I now have to be concerned about double the domain knowledge as before (remember, heterogeneous deployment across older sysV and newer systemd systems).
I know systemd is fun and it does cool stuff, I'll likely be learning it and using it at home if only because my home distro will use it; it's just that I only have so many hours in the day and both my personal and professional time is valuable. In this case I'm not yet convinced the benefits of systemd outweigh the time and opportunity costs of it.