Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon.
The grandparent didn't claim the former to be false, only the later to be true.
Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself.
Ruby is definitely wizardry but it's accessible wizardry.