This is a classic problem among engineers. The notion of bloat and cruft that goes unsubstantiated, and is really code for 'new and shiny'.
Older software projects offer more features, but that doesn't mean they're materially slower or worse in any objective way.
We use Rails at Pose to deliver JSON to over 1M users on either Android, iPhone, or our Backbone Web UI. It works well, it scales, and it's clean. No complaints.
Yeah. Just read the top comment (as I write this): "You don't need all the ceremony and structure of Rails and MVC."
I think the problem with this outlook is that you don't need it...until you, you know, need it. Rails has a lot of niceties that you lose with Sinatra. Why not start from a superlight Rails app (using any of the many gems or ActionController::Metal options) and then add on bits and pieces when you need one? I think that this method is either just too difficult for some people to wrap their heads around or it offends their sensibilities as a programmer.
I've had too many personal Sinatra projects that have bogged down when I started reimplenting Railslike functionality.
For me personally it's because Rails is so fucking slow these days. That's it, I don't mind having all that structure and ceremony sitting there. It doesn't stop me from architecting things however I please in lib/ and app/models/. But when it takes seconds for a brand new app to run `rake -T` it forces me to look for speedier alternatives. Speed will probably be what ultimately pushes me off Ruby as my bread and butter for good some day.
Personally I have never had any problems with speed when developing large projects with Ramaze, Sinatra or Padrino. In my experience this only happens to Rails. No clue why though. Maybe some gems used by Rails take too long to load.
To solve this problem is why Padrino was created. Padrino is a collection of "Railslike" functionality for Sinatra. So either start with a Sinatra project and then pick stuff from Padrino or start with Padrino in the first place. Padrino is highly modular.
What you said about bloat and cruft is partly true. But there are other things which sometimes substantiate it - boilerplate and cognitive overhead, for example; sometimes older things have more of these than necessary, and are kept anyway because of their maturity and usefulness (and because a community has already developed which fit its brain to the project and has memorized the quirks already).
That is a good reason to keep the old thing, but it does not mean that the older thing is always optimal or even better than a newer thing.
Older software projects offer more features, but that doesn't mean they're materially slower or worse in any objective way.
We use Rails at Pose to deliver JSON to over 1M users on either Android, iPhone, or our Backbone Web UI. It works well, it scales, and it's clean. No complaints.