Oddly, I didn't run away from Objective-C and Xcode screaming. But I have run screaming away from Ruby on Rails a number of times. I do acknowledge that this is likely a personal shortcoming though.
I haven't used RubyMotion, but Rails isn't really the best introduction to Ruby. Ruby gives you the ability to fairly easily create a lot of magic, but for just writing a Ruby program outside of Rails you can still certainly do things in a quite straightforward way where it's very clear what's doing what and why things are getting called. There's some really nice syntatic sugar and functional features that are, to my mind at least, much less "write only" than Perl's while giving you a bit more of that more-than-one-way-to-do-it flexibility than Python.
Ruby is cool. REPLs are cool. Objective-C is slightly weird. Interface builder is kind of nice. XCode is weird, but has some fairly great features for Objective-C/Cocoa.
But Cocoa is the thing you have to learn no matter what. To be honest, all things considered I would rather put up with Objective-C than lose Interface Builder and the niceties of XCode.
And I say that even though I have used and love PyQt. Cocoa is so deeply married with Objective-C and XCode, I can't really see the point of using RubyMotion.
You don't strictly have to lose interface builder to use RubyMotion, you can use XIBs with Motion, but [for now] addressing elements in the XIB requires a little bit of ugly manual mapping of the numerical XIB element ids to names you want to give them in Motion.
Disclaimer: I've not built anything extensive with Rubymotion/IB, but I have built a proof of concept. I don't know if it's really feasible on a large project.
Also, Obj-C and Ruby share many common concepts, using Cocoa from RubyMotion usually requires just a bit of syntax swapping, "vanilla" RubyMotion is not much of an abstraction.