Just because they "sponsor" MacRuby doesn't mean they favor ruby as a replacement for Objective-C. Until ruby is as fast as Objective-C, I see no reason they would make such a change. Low performance languages have never gained serious adoption on embedded platforms, which includes everything that has made Apple, Inc (not Computer) successful.
Maybe I'm a non-believer, but I also don't see any benefit to Apple supporting ruby specifically. If they were to have a higher-than-objc level API, I expect it to be an LLVM API which would be compatible with languages with an LLVM backend.
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.
Could not agree more. MacRuby exists, it's great. Use it. Who cares whether or not it will replace or complement Obj-C, sliced bread or even the internal combustion engine. GC is the key to the iOS port. Not there yet, so no option at the moment. Of course the future (maybe distant, maybe near) will bring GC to iOS and MacRuby with it. No need for reinventing the wheel.
Maybe I'm a non-believer, but I also don't see any benefit to Apple supporting ruby specifically. If they were to have a higher-than-objc level API, I expect it to be an LLVM API which would be compatible with languages with an LLVM backend.