A lot of this is solved by namespaces in Ruby (Modules.) Unfortunately, developers don't really apply them consistently. A best practice should be to put everything in it's own namespace. Been playing around with .NET MVC and C#, and this is something it manages really well.
But solid Ruby programmers use them this way and audit third-party code before using it and avoid it if it contains such code smell.
One of the fun things about Ruby is that you can open up, override and chain just about anything.
Apart from allowing for some interesting experiments, it also allows you to do things like monkey-patch faulty methods in libraries (including the std libs) at run-time while you wait for a sanctioned update to come out.
This may or may not be a Good Thing, depending on who you are and what you're doing.
I don't think global variables were mentioned in the article. Do you mean the global (top-level) namespace? If so, then yeah, "Don't do that" is pretty much the solution.
Sorry, maybe this isn't correct Ruby nomenclature, but I see Array simply as a global object, which can be modified, with rather obvious consequences. It's sad that I feel old enough to say this, but isn't this a problem that we solved a long time ago?
"Don't do that" is one solution, Alan Kay's idea of "worlds" is another.
Yup, proper use of namespaces would solve the problem, in part. Supposedly Rails3 will be using namespaces quite a bit more than the current version of Rails. That will allow things like mounting apps inside other apps, aka slices.
What I take away as the overall point of the article though is: monkey patch with care.