記事：Sinatra,Padrino,Sequel,HAML

Sinatra vs Rails
http://rubysource.com/rails-or-sinatra-the-best-of-both-worlds/
http://gihyo.jp/dev/serial/01/ruby/0007
http://rubysource.com/7-things-i-love-about-sinatra/

Padrino
http://jp.rubyist.net/magazine/?0036-SinatraReintroduction
http://jp.padrinorb.com/
http://cyberwave.jp/nashiki/2010/06/rails-%EF%BC%8B-sinatra-%E2%89%92-padrino-%E3%81%A7%E9%81%8A%E3%81%BC%E3%81%86%EF%BC%81/

Sinatra+Sequel+HAML
http://gihyo.jp/dev/serial/01/ruby/0009

誤解を恐れず極論すると：
SinatraはMVCフレームワークのC：コントロールだけ。request（入力）に対してどういう風にresponse(出力)するかという点に特化し、

• より深いコントロールが
• よりシンプルにかける=1ページしかないWebアプリならRailsよりも簡単で、
• システム寄りのコマンドを多用する「低レベルの複雑なRubyスクリプト」を使うアプリは簡潔で見通しが良くなる

M：モデルの部分は他のDBフレームワーク、例えばSequelにお任せ。コントロール部で使うRubyのハッシュをそのまま何の工夫もなくDBに保存したいような場合に便利。
同様にV：ビューの部分も他のフレームワーク、例えばHAMLにお任せ。Rubyのハッシュをそのまま何の工夫もなくtableタグでresposeページに表現したいときに便利。

その上で、Sinatra+Sequel+HAMLで作った単ページアプリをWebAPI風に多数作り、それらを纏めて一つのサイトにしたいとき、Padrinoを使い纏め上げる。

結論を言えば、最初からフルのWebアプリ＝認証・複数ページ遷移・複数DBアクセス・複数表示と機能出力を実現するアーキテクチャが定義されている場合は初めっからRailsを使った方が効率的。
個別の機能・ページを別々に作り、後で纏める様な作り方、特に個々の機能・ページがコンスタントに変化を強いられ、その度にアプリのアーキテクチャに変更を強いられるような性質のアプリならSinatraの方が柔軟。