What you state is not true of the whole family of rolling release distributions.
For a system maintenance software, it is much more challenging to resolve cross-package compatibility issues when upgrading only some parts of the system or maintaining configuration consistency throughout the upgrades. Various software packages need to be adapted to work nicely with each other.
That is why the easiest (i.e. most reliable at the same dev time effort) solution to provide a system update is to prepare a full, thoroughly tested, full-installation release periodically. Enterprise solutions such as Red Hat take the position that the client must be given a reliable system and be troubled by breaking upgrades for as long as possible. (Of course, minor upgrades and bugfixes must be available or even pulled automatically). This is also the general philosophy behind free server distros such as CentOS.
Providing the end-user with a seamless upgrade route between releases is a great challenge for the system developers. Many distros choose not to sacrifice their scarce time to this. Many popular packages (like QT for instance) are hard to upgrade, often needing a complete reinstall. What is even more important, many projects show a decrease in development effort or are otherwise displaced by new technologies. In case of system packages, this often requires some significant system redesign. Migration procedures can be especially difficult to implement if they have to take into account the fact that some people will want to upgrade from version C to D, but others will be switching form B or from A or from some custom state in the middle.
So, as you might already have guessed, the most challenging approach is rolling release. I don't know the details of Debian's approach, but from your description I can see they are somewhere in the middle.