Sarge contains a huge amount of changes (completely rewritten installer, lots of packages have seen multiple major upstream releases). It's naturally that such changes need a lot of time. So fewer changes are necessary. For that, we have to always keep the amount of work needed before release clear. So every change with potential to need lots of work afterwards has to be postponable to the next release with limited effort. That way, the worst case is always to undo that change. Experimental can play an important role here.
Of course, there are some things which cannot be easily undone by nature. Such things should always be done at the start of the development of a new release with preparations during the previous cycle. That implies that often some parts will be out of date or even largely unchanged from the previous release because updating them became possible only after some time past the last release.
Pros:
Time between releases could be made arbitrarily short (Just update some minor packages and call it the next release -> one week cycle)
Cons:
- Releases would sometimes not contain much exciting new stuff
- Often two versions of a subsystem would have to be maintained: One for backup in case the newer one does not make it for release
- Some parts of Debian would be out of date at time of release
- Overall progress would be slowed down
- This requires lots of self-restraint and some forecasting kills from developers