You are probably just comparing apples-to-apples here, then. Certainly: replacing Rails with Django or Symfony won't solve the core issues one has with Rails, because Djange and Symfony follow the exact same pattern and architecture.
But architectures (please note that I deliberately don't use the term framework here) like CQRS, Event-sourcing, Event-buses, Actors, Reactive etc. all fit much better for many use-cases than MVC.
All architectures have downsides and upsides. The one's I mention above with which I have experience have severe downsides in other areas. Some of those downsides are solved in Rails, some in other architectures. It's always about weighting trade-offs and choosing what fits best for your use-case.
So please don't just label everyone who made such tradeoffs and chose to forego rails because it doesn't fit them as "chasing fads".
If anything, blindly choosing Rails is just as bad as "following fashion": both is making decisions without any basis.
I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects.
Still yet to put my money where my mouth is on NextJS though.
No. It's not. It may be in your domain. But it really very much depends on the domain and use-case.
I daresay that purely on information density and amount of gigabytes, most data you use in your business is both document-based and hierarchical: files, docs, directories. But obviously I don't know you or your business, so this is just a wild guess.
This misunderstanding that "data is mostly relational", I believe, comes from the fact that it is easy to make most data relational (edit: to clarify: turning something into X is not the same as something being X to begin with). Much easier than to make most data document-based, indexed, hierarchical or into graphs. For one because the tools (RDBMSes) are mature and omnipresent. Practical: it's easy to put word docs and directories in postgres. But it's hard to have millions of CSVs with profile information accessible on directory structure
And, if what you say were true, that "most data is relational", then the best tool for most of our jobs would be a step-up in relationality from an RDBMS and we should be using graph-databases instead.
Most of our data isn't files, docs, directories. It's data given to us by our users or generated by our own processes. I'm not getting the reference to CSVs and word docs.
Yes, we store uploaded files but the metadata is stored in the database in a row that has some identifier that links to the directory where the file is stored. That works fine. We don't need a document database.
Building your own API to join data is absolute torture.
It's also a forthright description. Developers chase fads, the new shiny, just like everyone else does. Neither are we immune to cargo-culting; I'd go so far as to make the absurd comparison to web apps written in shell script to be an instance of this.
I've been behind the curtain on large Rails apps. Every issue you mentioned is either reasonably mitigated or exists more-or-less equally on other frameworks.