Thankfully we seem to slowly be turning it around though. If only on the front end, that is - with Typescript, Elm, Flow, Reason, etc. In Melbourne the Rubyists seem to be running towards Elixir hoping it will save them, but having worked on a number of Elixir code bases it seems that while solving some problems it leaves many still standing. :(
At least in Rails if you have to refactor you know what it should be refactored to.
Frameworks based in other langs have no concrete conventions and this willfully frees developers to write bizarre over engineer web-apps.
Any language can have tech debt, but I want access to tools in order to help me refactor my way out of that. Working with Ruby feels like building on a foundation of sand with mashed potatoes. It requires a huge amount of discipline to maintain a good enough test suite to combat code rot, and even then, a sufficiently paranoid test suite becomes a hindrance to change (not arguing against tests, just how much extra testing a dynamic lang requires of you if you want to have confidence). You have to refactor incredibly slowly, one small change at a time.
Dangling pointers are not an issue in languages like Haskell, and ML. We've had these around for decades. Thankfully most newer languages are banishing them.
It felt super powerful and refreshing when I was doing C++ daily. And after Perl it seemed like a nice improvement in syntax and readability to me.
But... Time has not been kind to my views on Ruby. All that promise turned to ashes in my day to day.
All that flexibility and expressiveness led to subjective code reviews and inconsistent styles across files, let alone projects, being worked on by the same team.
All that metaprogramming goodness lead to very robust, extendable classes and modules.. that were never extended. They were copy-pasta'd to a new codebase instead because testing the metaprogramming to support both variants was too risky for the project. And once there were two deployed forks no one ever approved time to consolidate them so then the third one was forked...
Working with Rails for some internal sites a couple years ago was like my whole Ruby experience in miniature. Started happy and very productive (ahh, generators! I'll just get my boilerplate started.. Rails guides! Actual documentation...) Then it was a little bumpy.. (Ok sure, convention over configuration. But where are the conventions listed? What options are there?).. And then magically working for almost everything. Then I spent three times as much work fixing the last 5% of my issues because they were poorly supported/unusual features, impossible to configure within the default Rails knobs, or basically just growing pains in moving from development to deployment environments.
I don't consider Ruby as a hipster language and I formed my opinions of it based on the core language not Rails. Not saying there aren't people who match your description, just offering a different view. I'd summarize it more as Ruby-fatigue.
Ruby "in the large" is pretty tedious and working with larger teams has lead to friction (even with good teams trying to be proactive with linting, style guides, code reviews, automation). So I still use it, but it's a "better Perl" for me now. If it's a one file script it's in bash/Perl/Ruby/whatever, if it's a couple files for a utility it's probably in Ruby, but if it's something new and I expect it to be more than that I'll pick something else.