Depending on your point of view, this is a perfect example of either what makes ruby so amazing or so awful. I don't know of another language that gives you the power to so concisely potentially screw yourself in such a creative way.
Just because something is powerful doesn't mean it can't be safe. I just got a handheld vacuum that has no safety mechanisms: no latches to disable the power button when it's folded shut, no kill switches when I take it apart. I can fold over the nozzle, take off the dust holder, and turn it on. I would never need to operate it in that way (unless I was using it as an air pump, which I could, now that I think of it), but it doesn't need any complexity to be safe, because safety is part of its design.
Similarly, a VM could expose a REST-ful API to its objects without needing to have any of the things which people find "unsafe" about Ruby (regardless of how valid those complaints are).
For kicks, go open script/console, type [].methods.size, and create a passing test for that number. It will fail, eventually. The code that kills it may surprise you.
as it should.
Would you hold the same view if you were tech lead of a team of a dozen engineers who've never worked together and loved monkey patching? You can agree to not monkey patch simply by saying "don't monkey patch" and hope everyone follows it, but then you'd probably need to and putting social processes in place to make sure people don't do it (e.g. code review), you can pick a platform that doesn't allow it, or you can recompile the Ruby runtime you use to disallow allow monkey patching.
Another option would be to automate some kind of monkey-patch detection in a staging VM that keeps a list of monkey patches in your code and publishes it to an architecture doc page. Then you can either call that list "tech debt" and strive to constantly refactor the code to get rid of monkey patches, or you can make it part of whatever communication the team does to discuss/agree on what monkey patches are acceptable to use globally in the system. In that case, you also have to make sure that whatever process is in place for deciding yay/nay on keeping a monkey patch treats everyone's contributions fairly. Etc, etc.
All in all, monkey patching is just one example of changes that affect the VM globally. Personally, I prefer that whatever complexity comes with global changes be dealt with by the programming team, not the VM designers (which is what the JVM often does), but I can certainly imagine a team where everyone is making global changes and nobody is aware of the complexity such changes bring to a project. Then everything simply stalls while people bitch at each other about X's code breaking Y's code because of dependency Z, the business guys start yelling because deadlines are missed, and the entire project goes to hell in a handbasket.