Although I see your point, I’m also somewhat amused that you lump bugs together with confusing settings in that criticism… in a post where you’re asking for another setting. 
(“But surely having a setting for stable/beta isn’t confusing, right?” Most settings are confusing only because there are so many of them. Each setting you add, even if it makes sense to almost everyone, increases cognitive load for the user, because they have more to go through when finding the setting they need, and because there’s a low chance that they’ll misunderstand any given setting–this becomes bad when there are a lot of settings.)
Part of the reason that something like Beeminder is hard to keep bug-free is that it has so many different configurations, because over the years so many people have wanted something slightly different. But in each combination of settings lie 1) possible bugs, 2) ongoing developer maintenance and support, 3) user confusion and overwhelmth. I wonder if the UVI thing has contributed to adding setting-sized features.
We did beta.skritter.com and www.skritter.com, and we would deploy the latest version of the code once a month to www.skritter.com while deploying constantly to beta and encouraging people to be on beta to get the latest stuff so they’d run into any bugs early. It was good for some things, but looking back, I think on net it made things more buggy, because some fixes would be on beta and not on www, and there were of course bugs with switching between the two and cookies, and having to keep the database formats in sync even as the application code changed, and versioning mistakes, etc. And I don’t even want to think about the extra problem for Beeminder of a user derailment being different across beta and and www.
If the Beeminder team wants to reduce bugginess, then they should 1) do object-level work on fixing bugs, 2) take the meta-level step of saying no to new configurations, and 3) possibly think about removing unneeded features to reduce code and interface complexity. But I don’t think reducing bugginess is the best goal. I think what they should do instead is decide what is going to make Beeminder the most money and work on that. Mainly listening to feedback from vocal minorities like power users is going to lead to niche features which are hard to keep bug-free while making the site intimidating for newbees.