Don't get me wrong, I fall squarely on the side that Ruby's power is well worth it's danger.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.