Version numbers and alpha/beta/delta labels vary and are subjective in practice. I've seen plenty of examples and counter-examples of version numbers and beta labels to not put much merit toward such labels.

Yes, it is unfinished. I'd rather have Apple do what it's doing -- i.e., releasing Swift as a beta and changing things with feedback -- than do the opposite, which would be keeping it closed until it was super polished as they felt it internally.

I hate seeing this "damned if you do, damned if you don't" scenario all the time.

(1) Pre-release for feedback, get complained at for it not being finished.

(2) Polish and release later on, get complained at for not opening it up earlier for public feedback and testing.

Apple has clearly stated that it's pre-release, that it's not set in stone yet, and that they're open to feedback (which they have been).

There's a big difference between someone's pet project language, or even an industry leader's new language in the ether, vs. the next crowned prince of an existing ecosystem.

Despite being backed by Google, regardless of how finished or unfinished Go was upon release, there was no impending pressure that you would someday more or less be forced to rewrite all your existing code in it. Thus the early adopter pros and cons were pretty clear.

This is not the case with Swift. At least if you take Apple at face value, Swift is the future of the ecosystem, which creates kind of a confusing landscape. Whether or not you should be writing your new app in Swift is a hard question. Whether you should just stand in the sidelines and not bother until Swift is more settled is a hard question. Swift is simultaneously in early adopter phase and industry requirement. As such, it is more than a little strange (arguably bordering on irresponsible) to make such a huge announcement when most of your own framework teams had never even seen or tried the language. I don't think there would have been any harm in getting internal feedback from your primary consumers before drawing a line in the sand to the general public.

  Despite being backed by Google, regardless of how 
  finished or unfinished Go was upon release, there 
  was no impending pressure that you would someday 
  more or less be forced to rewrite all your existing
  code in it. Thus the early adopter pros and cons 
  were pretty clear. This is not the case with Swift.

The way I look at this issue, is that for now Swift should only be used for pet projects and the like. Simple projects that help the developer gain experience with the language.

This is somewhat true. However, any developer who's got even the smallest amount of development skills will be able to make the leap from Obj-c to Swift with relative ease. Most of what people end up learning when doing iOS/Mac code are the frameworks, and they're functionally identical (except for syntactic difference of course).

Besides, isn't the challenge of learning new languages what makes being a developer fun? :)

It literally is unfinished!