MacRuby uses the native Apple Objective C stack.
Pros: Its class library is basically a wrapper for the Objective C GUI classes. You get fast native applications.
Cons: Only runs on Macs. They are not portable to the iPad or iPhone either (none of the Ruby solutions are).
IronRuby uses the native Windows .NET framework.
Pros: Use native WinForms to create rich native applications. It has access to the full .NET ecosystem of libraries.
Cons: Only runs on Windows.
JRuby uses the Java abstraction layer (JVM).
Pros: Multiple GUI libraries available. The most common ones are SWT and Swing. SWT uses native widgets and is faster and more native like. Swing is purely Java (emulated widgets) and is more portable. There are further libraries abstracting SWT and Swing to make them more Ruby friendly. Look at Profligacy for Swing for instance.
Cons: A layer above a layer above a layer. Swing and SWT are very mature but the Ruby layers above them are less so.
There is also another option
Ruby with the Qt library.
Qt is cross platform, uses native widgets and is written in C++. It is fairly fast but the library is complex and big.
My rule of thumb is the more complex your GUI is, the closer you should be to the native platform. You need to also evaluate the learning curve for each of these graphical libraries and the effort needed to port between platforms.