I'm afraid I can't comment on Django or any of the PHP frameworks, but have been thinking about this question myself lately as a junior developer (started my first job in January of this year) who's been working on my company's long-running rails website. I can and will, however, compare it to java and javascript (which may be of more interest to other people reading this than the OP)
Emphatically, RoR is not "really bad". Some of the world's most successful, high-traffic websites run on Rails- AirBnB, Github are the first two that spring to mind, and Twitter became HUGE in terms of its user base on Rails before the performance limitations of Ruby became an issue for them. As a matter of fact, as someone who was hired as a Java developer, I've come to really like working in Rails.
Once you've become accustomed to the "Rails magic" that associates active record models with database entries, it's wonderful not to bother with the tedious plumbing associated with the Java side of our stack. If I add a field to an object linked to the database by Hibernate, I might have to modify 6 files in Java or xml, with previously working code breaking if I miss one thanks to Java's strong typing. In Rails, if I change the database (not the "Rails way", but never mind) I'm done, without verbiage and with nothing breaking. I don't have to write a single line of code to be able to access that data from my object. I've not used any ORM tools with Node.js, but from what I've read there's nothing that compares to Rails' Active Record. (I believe Javascript's preference for NoSQL solutions reflects the fact that Javascript finds classes as templates slightly distasteful. I'm sympathetic to what people like Eric Elliot say about the virtues of prototypal vs classical inheritance, but sometimes what you really want is a cookie cutter when you're trying to turn out nice neat identical cookies.)
Ruby itself is in my view an extremely nice language to work with. I'm a fan of dynamic typing: if you need a function that adds two numbers together, there's no need to overload the function definition for every possible combination of ints, floats, doubles, ... that your user might enter. Its code is similar to Python's in its virtues- it's extremely readable, which is by far and away the most important thing for the maintenance of an app. I actually prefer its syntax to Python's (I vastly prefer def ... end to meaningful whitespace, for example- I distinctly remember staring at a Python method trying to work out which line was inconsistently indented. If I recall correctly, it turned out one had tabs when the others were 4 spaces, or something like that.)
The thing people always say about Rails is that it's opinionated. It expects you to do things in a certain way, right down to the naming of your variables in snake_case. In some ways this isn't necessarily a bad feature for a project that will outlive the career at a company of any given developer who works on it. (One of my predecessors, for example, decided to abbreviate a Javascript variable representing a customer's phone number by "tlf", because he was Spanish.) Knowing that something is a Rails app allows a new developer (who knows Rails) to find her way to what's going on quite quickly. It can, however, make it impossible for a developer unfamiliar with Rails to figure out what's going on. Some of these opinions are the price you pay for Rails being able to make assumptions about the "User" class mapping to the "users" table (which in my view isn't really a price at all.)
One of Rails' opinions is that it's based around the management of resources. Any Rails tutorial you can find will revolve around something like a blog post, with attached comments, made by a user who has a username and an email. These are largely dumb data objects with relationships between them (a user writes a comment which is attached to one particular blog post which has many comments attached to it.) Rails makes manipulating such objects easy- if for example, you want to destroy all comments by a particular user when you ban them from the site, Rails makes that almost trivial. It takes a single line of code to match up 7 http requests to urls you don't need to specify explicitly to actions that perform CRUD operations: so the line map.resources: blogpost
tells Rails to display the blogpost with id=1 in the database when the user submits a GET request to www.myblog.com/blogpost/1 and that a POST request to the same URL creates that blog post, and some other stuff besides. You can think about how all this would work brilliantly for AirBnB.
Delving in a bit more deeply, Rails has a router-model-controller-view architecture. Your router decides to send a request to a given controller method, which does the bare minimum of work necessary to display a result to the user in the form of a view (normally a dynamically generated html file with information about some object presented to the user). Having an actual directory structure that reflects this pattern is one of the many Rails conventions.
Within this prototypical architecture, some complex logic can find itself homeless. If you were writing an app that plays chess, you might have models that represent the players, the board and the pieces, and the pieces might know the rules governing how they themselves move, but where do you stick the logic that decides what to move where?
The canonical answer to this question is in a model. Perhaps most obviously in the "player" model. But then in this case, you'd have 99% of the logic of the app in one file. (Chess is hard.) And it wouldn't be relevant to the model of the human player, and would obscure all the logic for keeping track of that player's most crushing victories. Controllers are meant to be "skinny"- they allow the user to tell the computer to move Kb1 -c3 , and that's about it. And sticking the thinking in with the html is right out. One option is Rails' 'lib' folder, but some people prefer to reserve this for code that can be reused across apps.
To be honest, this perhaps isn't actually more of an issue for Rails than it is for another project. Writing a chess app is not easy, so it's not obvious to me how you'd actually break it down into manageable jobs. Once you'd done this, there's no reason why you can't write classes in the "models" folder that do these jobs, that just don't happen to correspond to anything in the database. But because Rails is naturally so opinionated, it would feel weird. Many people have probably been seduced by Rails' default settings into writing bad architectures when an important concept doesn't naturally map to a database table, and have then gone on and blindly tied those architectures into their database. This then makes that much harder to re-write than just poorly structured code, as customers still need to be able to get to their data.
Apologies for the length, but I hope it clarifies some of the criticisms you've heard.