What’s wrong with a moving target release mechanism?

Recently, Slashdot posted an article</a discussing some grumbling in the Debian community that the release cycle for the platform should be quicker.
Debian's system is split into several releases – stable, testing, unstable, etc. The 'stable' 'release' hasn't been snapshotted as a 'release' in several years, and therefore is running some fairly out of date applications.
However, the 'testing' release is what I consider a 'rolling' version. It has no specific snapshot of the platform and applications that folks need to upgrad e 'to' or 'from'. I've installed Debian testing on the last 2 laptops I’ve worked with, over the last 14 months, and even though the actual packages and environment that went into each differed, and even though there was no ‘release’ I was installing from, everything worked great, and was completely up to date.
My point here is “why does there have to be a release schedule”? Why can’t a platform track the current versions of applications, and use normal update mechanisms to make sure new versions and updates are synced into place?
I will, btw, accept there are a times a total clean cut from scratch may be necessary. Major kernel revisions may be one such (though ‘testing’ is distributed with a 2.4.x kernel, and installing a 2.6.x kernel was a matter of just apt-getting the appropriate files – and they are still maintained and updated via apt).
This is actually one my biggest beefs with Redhat and the spinoff Fedora projects. They are still stuck in a ‘cut and release’ model, when what they should do is distribute a simple baseline, and then the users net-update against the baseline up to the current version, much as the Debian Network Installer does now.