The problem with saying "you can do things in whatever
way you want in Ruby" is that the moment you have more
than one developer it collides rather drastically with
the "principle of least astonishment".
I've solved that problem by actually talking with the other developers and agreeing to some common practices.
Not every problem requires a technical solution. Social solutions often work just fine.
That works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler.
One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everything else." His response, "Wait, how do you free memory?"
I had the opposite problem at a student intern gig. I hadn't experienced smart pointers before, and was double freeing memory accidentally. The fun part was that the unit tests for my code always worked. It was always someone else's code which appeared to break inconsistently after my change ;)
You live, you learn. We picked it up remarkably quickly in the end, basically because the company had their process working right: clean codebase, solid testing, and regular code reviews.
Not every problem requires a technical solution. Social solutions often work just fine.