I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails.
Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.
This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.
My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it...
However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.
I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.
But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.
Great when building but it sucks when debugging and maintaining.
The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels.
There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.
Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app?
Legacy is where conventions actually shine!
Padrino (www.padrinorb.com) is a sinatra-based 'rails without the bloat' framework.
It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!
But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.
Blaming the tools is completely reasonable if your problems can be solved by better or more appropriate tools. If I need to drill a hole precisely and accurately and the team or management has standardized on hand drills, it's entirely appropriate to bemoan the use of hand drills versus a proper drill press with an appropriate jig.
Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.
This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.