Using XIBs is also great for universal apps. I can instantiate the same controller with one XIB on iPad and another XIB on iPhone, and the layouts can be tailored to the platforms. It's wonderful when a client comes to you asking for an iPad version of their app, and you can duplicate the XIBs, scale them up, resize controls and swap out assets and go home early.
One thing that does suck about XIBs is that they ALWAYS cause merge conflicts. That part sucks and really needs to be addressed (at this point, Apple would probably have to write a diff tool for XIBs!)
It's really variable. XIBs have issues with source control, but they can be very useful for bringing in assets without needing a load of boiler-plate image loading code. iPhoto, for example, is laid out programatically but most of the controls are coming in from XIBs.
This doesn't scale when doing projects where the UI tends to be redesigned every few days.
In a few hours it is possible to design UIs that some require days to do it.
No, not at all. Especially in iOS.
Perhaps other iOS developers can weigh in on this, but I feel like it's fair to say that the most qualified developers do everything programmatically.
I've been doing everything exclusively programmatically since I've started, and I've never had any problems with XCode - to the point where I was surprised when I heard people complain about it for the first time.
From that point, the only downside I see to using Objective-C over Ruby is verbosity, but that seems pretty inconsequential given some of the benefits sandofsky mentioned above.
It's nice that there's something out there for experienced Ruby developers though.