One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus.
Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc.
You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing.
To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground.
I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other.
And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.
I worked with Django full time for about 6 years. It scales up and out pretty well, too.
There was a peer comment about Rails. I'm a big fan of Rails, and Ruby is one of my favorite languages. But one thing I've noticed is the lack of magic inside the Django codebase vs. Rails' codebase. Spelunking in the codebases feels night and day different: I found Django very intuitive and Rails... less so. I think that was a combination of my lack of skill with Rails' internals, and the different in languages and communities. Python (and Django) try to follow the Zen of Python. Rails felt like every other method was monkey-patched and reduced to a single line or two. It was odd: I think the expressiveness of Ruby was actually a negative at large scale (sort of like Lisp vs. Go)
For 99% of use cases, you never need to get to this level of the frameworks, but it was an interesting experience.