First, the boundary between Linux and the rest of the system is very well-defined. I can run my userspace on top of multiple different kernels, since my userspace is loosely coupled to Linux (yes, there are exceptions, but not so many that it prevents GNU/kfreebsd or GNU/solaris from working, for example). This is not the case with systemd, which over the past several years has been subsuming larger and larger swaths of userspace, introducing all sorts of tight couplings and inter-dependencies that weren't there before.
Second, the pace of innovation in Linux is definitely slower than in userspace, and getting your patches adopted is more difficult relative to most userspace programs (this is the high barrier to entry I spoke of). Your patches either have to get approved by Linus et al., or you have to host them out-of-tree and hope your users know how to apply them and compile the kernel themselves (and if you want to do this for them, you have to do it for every kernel you need to support). If you're lucky, your patches can be isolated into a kernel module, in which case you "only" need to keep it up-to-date with the kernel API (which is a moving target).
Contrast this to working on a program like, say, xinetd. While the option for submitting patches still reduces to "go through the maintainer" or "host them yourself", the "host them yourself" option is much more tenable, since the codebase is smaller, and the "don't break userspace" policy Linus enforces ensures you aren't coupled to a moving-target API. The lower barrier to entry brought on by loose coupling explains why Gentoo can get away with forking udev, but not large swaths of the Linux kernel.
Systemd has the effect of making innovation in the plumbing layer (xinetd, syslog, udev, cron, etc.) a lot like innovation in the Linux kernel. Can you imagine the absurdity of having to maintain a version of xinetd for each separate systemd API change?