The past four years were a period of relative stability in open source software. Most things just worked together nicely. But we're now entering another period of instability and upheavals. GCC 4.6.x were unusable; v4.7.2 seems to be better. Glibc 2.15-2.17 are unusable; I'm sticking with 2.14.1. More and more packages are refusing to be built by root, and burying this fact deep inside and late in the configure process. Iptables is going through another period of great change. Even OpenOffice/LibreOffice are becoming unusable; KDE *is* now unusable. There's too much being moved around and changed; it will take time for the rest of the OSS world to catch up.
Working to enhance and update a firewall distro, I know what is involved. If you leave out the kernel, binutils, gcc, glibc, udev, grub, iptables and a few other core packages and concentrate on just one 32/64 bit arch, then it might be possible to keep most of the userspace software up-to-date on a rolling basis. Maybe even the kernel could be updated a couple times a year. But it will never be possible to update *everything* on a rolling basis.
To put it simply, OSS instability is unpredictable. To be fair, it seems that there is a period of OSS upheaval every 4-5 years followed by 3-4 years of relative calm. If you can set a rolling release's base near the end of a 'calm period', then you might be able to ride out the storm of upheavals in the base packages while continually rolling out releases of packages that remain fairly stable.
But if 'rolling release' means to jettison the stable core/foundation, the product will end up about as stable as an ark in a hurricane.
Remember: users want systems that work, systems that have fairly stable interfaces. They don't want to relearn how to use their computers as tools every few months or years. Poorly planned rolling releases will put people on the roller coaster of heavy seas when they *really* want to be in their cozy offices using their computers as tools to make money.