The "no major updates to stable releases" policy would make life very uncomfortable for certain applications (both maintainers and users). Since I used to maintain Banshee I'm basing my information on that. Banshee tends to release a new version every 3-6 months, these releases tend to roll up a lot of fixes and desirable functionality. Add to that the fact that upstream naturally has an interest in only supporting what is their latest stable release this is what they ask, what users ask (for fixes and features). The advice is nearly always to run the latest release for support and historically the risk of regression is very low for this package (and likely many others with as competent upstreams in terms of testing). This puts the maintainer in the position of either needlessly spending man-months backporting fixes without support from upstream or upgrading to the latest release - you now propose that the latter option is to be taken away from us. The cost is simply to high for such packages to support any such move.
Fedoras strength to me has always been not just it's involvement with upstream but it's trust that upstream continues to produce quality code upon which we can rely. For upstreams where this is not the case I could see applying a black list, like the critical path packages have and engaging those upstreams at a distribution level with advice and help on how to improve. For everything else, additional encouragement of updates-testing as well as integration between bodhi and packagekit to provide feedback should be sufficient, if it is not that is a failure of upstream, not Fedora and should be dealt with there.
Another thing we could do would be to bundle updates in monthly service updates so that anything that isn't a critical security, crasher or data corruption/loss update goes in regular service updates which the user can rely on. This would stem the flood of updates a bit and hopefully encourage more users to pull in specific packages from updates-testing or even enable it by default if adventurous. A policy should be enstated so that the first 2 weeks of a month you can put new updates in the queue (akin to the kernel merge window), after that it needs to live out it's life in updates-testing for at least 2 weeks with positive feedback to be bundled in the service update. This gives maintainers the knowledge that if they miss an update window another comes along shortly and they can focus on bug reports till then. As updates-testing remains as a viable testing ground to point users with bugs to for pulling down specific packages this doesn't deprive them of access to testing or a rapid turn around. For this policy an update should be stated to be begun within the merge window, fixes applied to issues discovered in the 2 week trial period should not push the update back to the next merge window - we reward active work on bugs rather than punish it.