> Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery.
I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.
Totally anecdotal, but the past two startups I worked at used Rails on greenfield projects.
The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result.
The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess.
The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project.
What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.
I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.