Personally, I see it like this:
- You want to get feedback from your users as soon as you possibly can. The sooner you know what you're doing right and wrong, the better.
- Most users will not use software that is too buggy for their needs. Furthermore, you won't know if the software fits the needs if it is too buggy.
Bottom line is... beta is ready for the public. Alpha is not. To me, the distinction between when something is ready for beta, versus staying in alpha, is whether or not the public will generally be turned off by the state of the application. If it's too buggy to really be of use to them, not only are they not going to use it very long, but you're going to get a lasting reputation for having a poor application. So it really is a matter of your user base and their tolerance for bugs.
If you have a very technical crowd, many of them will be "more understanding" of bugs and are able to see past that for the better elements. If you have a "more casual" crowd, they might not care about the poor functionality as long as the graphics are crisp and there's transparency and other useless/strictly visual aspects. It goes without saying that a keen understanding of your user base is essential for EVERY aspect of a project, and this is no exception.