> there is nothing special about it.

One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.

It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.

In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.

At that same flexibility in monkey patching makes the codebase rubbish in a year when it's time to upgrade dependencies.

It really depends on the interaction between the discipline of your team and the failure modes of the tool. A culture of code review which puts a high bar of justification and documentation-for-new-contributors on monkey patching can counteract this failure mode.

Do you code review what each new library does? It doesn't have to be code you wrote to cause problems. And most people treat a library as a black box with inputs and outputs. Which works well in a sane language, but often not ruby.