I think your decision makes a lot of sense. Even though I'm not beta testing SBR, I was worried by the changes that were being made to the basic gameplay late in the game. These strategy behemoths take a lot of time to tweak and adjust -- just look at [At The Gates](
http://www.atthegatesgame.com/) made by Jon Shafer -- this puppy's been in the works for a LONG time, and it's still being tweaked (actually, also check out the amazing UI he developed while you're at it). In general, I think that the more revolutionary a game is, the more you can afford to release it in an unpolished state, since the mechanics alone will draw people and there's no point of comparison. A turn based strategy game needs to really get the mechanics down because it'll be immediately compared to hundreds of other games.
My main advice for the next game is to zero in on the core mechanics that need to be fun, and the things that could be simplified. You guys have a tendency to create overly-complicated mechanics or stories that then need to be connected somewhat unnaturally to gameplay mechanics. The main example that popped into my mind right now is the mechs in Bionic Dues. I fully expected (as I'm sure every other player did) to have 4 bots to control. Since you determined mechanically that only one bot should be controlled at a time, having 4 bots didn't really make sense. Why wasn't it changed to having a transformer robot with 4 forms?
Anyway, I think that one asset you have here is a lot of smart, helpful people on this board. The problem is that relying on forum posts gives you a really bad skew. Many people don't have time to write long posts, or don't feel as strongly as other people about certain points. I think (non-anonymous) surveys might work really well here. You could list every system, and let people tell you if they thought those systems were fun, well polished etc. Since you tend to have such an open development process, you could even get feedback on your design document. Surveys could really eliminate the shouting match that happens when you post a change and then want feedback.
Another issue that I remember coming up a lot in previous games is that there will be a design issue, at which point everybody will give their loud opinions on the forums. You'll go away for a bit and say you've come up with some solution but want to code it first, and then you'll come back and the solution will be... mediocre. It does the job, but it creates other problems. But it's already coded, so you're not going to criticize it, and certainly it's not worth getting into a forum shouting match with other beta testers over it. Stating your solution before coding it, and then making a survey about it to find the potential faults, could really help avoid that. You could then discuss the results of the survey in a forum thread to allow the crowd the cross-polination needed to pinpoint the design flaws. It'll hopefully allow you to crowdsource the potential issues in your proposed solution before you've needed to code them or even worse -- create art for them.
The bottom line is, iterations are expensive once you have a lot of good art, which you must have in order to compete in today's market. A huge part of iteration is getting feedback from many people, because as the dev your natural human biases act up everywhere. That's difficult to do in a tiny company, and the other difficult part is, how to use the limited resources you have to iterate efficiently, and with as little materialization as possible.
Sorry for the rambling post.