* Knowing which version of the installer you are using, so you know which versions of what are gonna be installed by default, sometimes the installer itself will contain bugfixes (but not always).
* Knowing what is the minimum patchset applied to a system. You can check the etc release files and get a summary of the updates applied, eg.: if you see release 10.2 you will know that at least all of the patches up until 10.2 were applied. This one is very useful if you are debugging a system and want to get an overall idea of how up-to-date it is, if you are debugging a system that it's behind the latest updates, you should always consider that as a possible cause, knowing which is the point release allows you to reduce the diff/bugs you will be looking at.
> I'm running Debian on all my servers, but on the desktop I'm in love wit the rolling release model.
If you run it on you servers then you know that Debian supports many rolling releases. Experimental, unstable, testing, stable + backports, stable + updates, stable. The difference is how fast they change, ranging from "in front of the bleeding edge" for Experimental to "for the very patient" for stable (and beyond).
This seems to be how Debian does things. There aren't separate projects like kubuntu, lubuntu and whatever. There is just Debian, plus what seems like every Window manager under the sun packaged as "task-kde-desktop" or whatever. And so there isn't the a Debian rolling project. There is just "Debian testing" or whatever, which is well, Debian, but the snapshot is taken at difference times and frequencies of Debian's life cycle.
Rolling upgrades are nice on the desktop, where you are computing more and more in the Mobile paradigm, where all software disappears behind an app store gateway.
There are places in the world where internet is not accessible, maybe for you it's a commodity but for some people is easy to burn a CD and send it to those who needs it.
* Knowing which version of the installer you are using, so you know which versions of what are gonna be installed by default, sometimes the installer itself will contain bugfixes (but not always).
* Knowing what is the minimum patchset applied to a system. You can check the etc release files and get a summary of the updates applied, eg.: if you see release 10.2 you will know that at least all of the patches up until 10.2 were applied. This one is very useful if you are debugging a system and want to get an overall idea of how up-to-date it is, if you are debugging a system that it's behind the latest updates, you should always consider that as a possible cause, knowing which is the point release allows you to reduce the diff/bugs you will be looking at.