I think the lesson here is that the circumstances at times compel platform vendors like KDE and Gnome to make these big next-gen releases, and the market compels them to do them before they're quite ready for end-user primetime, because the alternative is a serious loss of momentum, e.g. in the third-party space that is waiting for that release. And this is likely even more true in the FOSS space, because you're not just bleeding third-party interest by not shipping, but also developer recruitment.
It's a balancing act. Looking back, I don't think we found quite the right balance with KDE 4.0. But realistically, shipping 4.0 only when it had achieved the quality level, of, say KDE 4.5 just wasn't going to happen, either. Because if we hadn't shipped at some point, we'd might not have gotten the influx of contributors and early adopter feedback that we needed to make 4.5 happen.
Really, people are being presumptuous by saying these things happen carelessly. The reality is that there are pressures pulling you into different directions. You sometimes make bad calls under pressure. At other times you make the right call but get to chose between multiple options that each have their own downside attached.
Call it "4.00001" or "3.9999". It seems to me that you could get people's attention and so get test users while still trumpeting the software's "not-completely-finished-ness".
a) It's not all about beta testing. A big thing is developer recruitment. The demographics among FOSS developers ensure a relatively high amount of turnover: Many of them are at an age where their life and/or job situation is likely to change within two-three years, causing them to move on. A steady influx of new talent is needed to keep the show on the road.
At the same time, a project that isn't releasing is less attractive to contributors for a variety of reasons: The time it will take for your handiwork to be delivered into user's hands, the level of information circulating about contribution opportunities (i.e. "what does this even do that I might want to hack on"), et cetera. It's also still true that a lot of FOSS contribution is itch-driven: You start contributing because what you're using isn't doing quite what you need it to. But if you're not using it, if there's no exposure, there's no way for the itch to happen. And usage explodes with a real release vs. a beta.
b) People don't test betas, relatively speaking. The amount of feedback explodes for an actual release. Now you'd think that beta feedback would be of higher quality on average (due to people who actually do test betas being more advanced users), but even expert users often hold back on betas despite knowing better.
