Of course, this would seem to suggest that you assume that evolutionary releases are introducing more bugs than they fix with each successive release. I'm not sure that this is not the case, otherwise software would simply get worse and worse over time, when I've found that software such as GNOME and (Linux) gets more reliable and stable over time.
The argument is that staying with the old branch and only backporting just the fixes is a good thing. It works whilst the upstream supports it (usually about 6-12 months) but then you are forced to backport fixes to older versions that were never intended to have those fixes. Things break.
Red Hat have admitted this in person to me during subscription negotiations: Red Hat tend to break things badly by back porting critical bug and security patches (as well as new features). They fix security bugs and then they have to fix the fix because it exposed code paths that were never seen upstream.
So, customers should compare the latest stable versions of the software from upstream with an older version being maintained by Red Hat with new features/fixes (cherry picked ones, note!) backported over the top in a way that was never designed.
As you say, newer releases introduce *new* bugs (whilst fixing old ones) and *new* features. I don't really like the Enterprise Linux releases (they are obsolete at release and the package set is small) or the non-enterprise ones (Huge package set but insufficient testing, lots of new untested features, short lifespan). There has to be some middle ground we can get to.