Rails can take you much further than MVP though, as evidenced by all of the companies that reach breaking point with it. Basecamp, Github, Shopify - all reached proper business status on Rails (arguably Twitter too, although business is a bit of a stretch...).
We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.
> A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes
I see it as the opposite: it's clear which functions are the responsibility of which library, and it's easy to replace the ones that are becoming blockers and leave the ones that aren't. Whereas with Rails if you keep it monolithic then upgrades always become a huge pain point, but if you try to cut out pieces of it you're going against the grain.
(I used to love TurboGears nearly a decade ago, because you could use it like a monolithic framework to start with but it was explicitly a collection of standalone libraries underneath, and so once you started needing to do different things to individual pieces it was easy to. The modern web ecosystem could do with something like that, IMO (though personally I'm sticking to ScalaJS for the type safety))
We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.