All the other stuff you speak of falls in the same category. It's all great code/libs, they just need a CLI so they're not stuck in the monolithic Rails Rakefile.
The good news about Rails 3 is that it fully embraces Rack, so the plugin ecosystem you speak of is much more portable these days if you want to run it in a different framework (I'm thinking of libs like OmniAuth, etc)
Alas, I would never recommend an architecture on the merits alone that you can "swap out the backend". That doesn't really add that much value to end users and never really happens quickly or easily in the real world. The benefit I describe in the blog post to the view layouts and logic being separate is that you get an epic win on the content delivery side of the house. This is a huge deal for mobile web apps.
Sinatra + Sprockets + Sequel seems to be perfectly reasonable.
The whole point of this post was using a complete frontend on the client side. Like backbone. You don't render backbone using a server-side template -- it's all done on the client side.
I'm not saying throw out all your old tools. I love using Makefiles. I'm saying use the right tool for the job -- and my opinion is that to have a separate client side app like backbone and a simple server-side API, Rails is way overkill.
With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.