The language: Tech companies are becoming more aware of the dangers posed by maintaining and updating large codebases written in an untyped language. I know there's a lot of work still being done in Rubyland on this problem but it feels like the horse left the barn long ago. A lot of Rubyists seem aesthetically opposed to types, including influential language stewards. Sorbet is arguably the Typescript of Rubyland, but it doesn't feel like it's taking off to nearly the same degree. (My theory is that the expressiveness required to support a language as flexible as Ruby results in poor developer ergonomics in terms of the necessary type annotations.)
The ecosystem: Rails is still king, for better and for worse. Back when Rails was in its prime, there weren't as many CRUD web use cases that required marshalling lots of async i/o. Now it's a pretty ubiquitous requirement. You need to fetch data from upstream A and upstream B, then combine them to send back to the client. With Rails, the de facto way to do this is to make these requests serially, which isn't very scalable. Hell, even a single call to a slow remote host can easily end up saturating all of your web workers. Like the types issue, there's a lot of work happening trying to make it easier to perform non-blocking i/o in Ruby/Rails, but it seems like too little too late.