Ruby doesn't run better per se -- or at least I cannot see how it would.
However there are parts of Ruby that you can have access to that do not exist in the core version distributed with Windows Sketchup installs -- If they want to use any of that extended functionality plugin authors have to add those parts into their plugin for Windows users. It's not a huge issue but it is certainly a limitation (not something you are likely to worry about unless you get into Ruby coding -- which I will if Layout gets a API).
Here's a quote from: http://code.google.com/apis/sketchup/docs/faq.html
@unknownuser said:
What are the differences between the Mac and PC when it comes to the Ruby API?
The biggest difference between the two platforms are the WebDialogs. On the PC, the embedded browser is Internet Explorer, and on the Mac it's Safari. See the WebDialog documentation for details about all of the differences. if you're not using the WebDialogs for anything, then you don't have to worry about it.
Another difference is the fact that the Mac supports "MDI" (Multiple Document Interface), meaning there can be more than one SketchUp model open at a time under the same SketchUp process. This can cause Ruby scripting challenges if your code is doing something with an entity only to have the user change the active model out from under you. There's no easy answer for how to handle all of the potential problems with this... it's probably enough for you to be aware of it and be sure to test what happens when a Mac user changes the active window while your script is active.
Finally, there is a difference in the way that the Mac boots up SketchUp that you should be cautious about: there is no Sketchup.active_model when the Ruby scripts are first loaded. So if your script is making changes to the active_model at load time, it will not work on the Mac. The answer? Ensure code that references the active model is part of a UI event handler, responding to the user selecting a tool or a menu item. You can also use an AppObserver to get a callback whenever a new model is opened, at which point it's safe to talk to the active_model.
Best,
Jason.