Measuring and comparing the "fastness" of a language is a tricky thing in general, but I think it is safe to say that for most intents an purposes we can consider MacRuby just as fast as Objective-C. The point you seem to be missing is that both run on top of the same runtime and both use the same foundational classes. So the same operation performed on a MacRuby String and Objective-C NSString should take exactly the same amount of time.

The only thing that prevents MacRuby from being fully compatible with Apple's "embedded platforms" is the lack of garbage collector on said platforms. By the time MacRuby is sufficiently stable and optimized Apple's portable devices will be capable of comfortably running memory managed code.

As for the "LLVM API", for one, I don't really understand how is that supposed to work - there is no "native" LLVM language and so on; for two, such an API will be lower-than-objc, not higher; and for three, reimplementing Cocoa and CocoaTouch as some new supposedly more abstract (whatever that's supposed to mean) API is going to be a monumental and almost certainly very disruptive task - and all of it for no good reason.

A lot of the comments, I'd say yours included, seem to be coming from the presumption that Apple's adoption of a higher level than Objective-C language is inevitably going to be a huge overnight change. But the beauty and genius of MacRuby is precisely that it does not require a huge overnight change. You can mix and match Ruby and Objective-C as you need or like. You can write high level, terse code using the HotCocoa wrapper or you can fall down to the nitty-gritty OS X C APIs, for a good number of which there are MacRuby bindings.

Btw, Apple is not "sponsoring" MacRuby. Apple is developing MacRuby, it's an Apple project. Will it replace Obj-C? Probably not. Will it become a blessed alternative? Everything seems to point in that direction.