The problem comes when that codebase starts to mature: you look up one day and realize that it's no longer just you working in the codebase. The lack of language-level documentation makes it difficult to onboard new members to the team. A new developer is inspecting a method they're tasked with refactoring. It accepts an argument named "input". What the hell is an input? Is it a hash? Is it a class instance? Both? Something else entirely? Idiomatic Ruby/Rails makes it quite hard to intuit expected inputs/outputs. (Ironically the community also vocally disavows the use of comments, which would ameliorate that problem somewhat.)
Meanwhile, "Undefined method `blah` on nil:NilClass" errors start to litter your logs to the point that developers become numb to them. Invariant violations that should have been caught upstream, at their point of inception, sneak all over your runtime and you waste valuable employee hours trying to identify their true source.
And Ruby's poor story around async i/o ties your hands as your traffic patterns begin to require a more sophisticated request processing pattern than "receive request, block thread, return response." Phrases like "worker saturation" and "let's make it an async job" start to dominate your engineering retrospectives.
These are just a few of the sharp edges that come from trying to scale Ruby. You may point to solutions to them, but they don't compare in elegance to working in a language that obviate those problems in the first place. And while it's very easy to start a project in Ruby and gain a quick initial burst of momentum, it's commensurately difficult to switch to a more mature language+framework when you realize that your engineering org is suffering from Ruby/Rails shortcomings.
This is not a blanket indictment of Ruby/Rails -- just an acknowledgement that different languages and frameworks are better suited to certain types of problems. In my opinion, Ruby/Rails are very well suited for small projects with few maintainers, where the total surface area of the domain model is pretty small. Or quick MVP's where you have to deliver next week or die. But the dynamic duo are not well suited to the kinds of problems that start to emerge as those MVP's scale up in complexity/LOC/number of maintainers. It's a bit of a catch 22.
People will point to the big companies running Ruby/Rails. But from having worked at one of them (Shopify), I can say that we were spending an inordinate amount of time trying to plaster over their shortcomings; I'd imagine this is also true of the other big companies that run on the same stack.