Since it was "optimized for developer happiness" (https://news.learnenough.com/ruby-optimized-for-programmer-h...) it's more likely to be easier to understand, document and maintain.
I specifically left Rails and Ruby because I failed to see any production Rails code actually meet any of those criteria. All of the metaprogramming, OOP, inheritance, and DSLs just made the code more confusing than it needs to be. Ruby is a cult of "the code documents itself", but code can never document itself, because good documentation includes the how and the why and some examples. Code is a horrible at describing how it exists, and no, unit tests are often not sufficient examples. And then there's the issue of Rails apps taking way too long to boot up despite their only job being to serve webpages. Debugging serious issues is a pain when the Ruby code takes minutes to actually run, and having neither clear nor documented code doesn't help. It's always abstractions upon abstractions upon abstractions.
But some people like Ruby because it's a beautiful language and Rails gives them an opinionated structure, and maybe that matters more to them.
I'll take simple functions and primitive data structures with detailed comments any day over design patterns with a bunch of classes to describe abstract ideas that inherit from one another and fail to self-describe.
It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams
Should check out Java Spring (and for a bonus round, Lombak). So much magic pixie dust spewed around to get around not being able to monkey patch.