For starters, I would use Sinatra where you use Rack.
It takes care of a lot of unknowns for a lot of people. For instance, it makes sure you do proper redirects. Did you know that IE9 implements 302 like 307 but only for redirects from Ajax? But you can't simply use 303 as some HTTP clients don't properly implement it? Rack does not care about such things.
It also comes with built-in security, which Rack does not.
If you are comfortable with Rails and it suits your needs (that is, a monolithic model driven application), stick with it, there is nothing wrong with Rails.
you can use sinatra in place of rails for dynamic sites, but you'd need to pick template language (erb, haml), object relational model (activerecord, sequel, datamapper), and other things that come bundled in rails. that's what makes sinatra lightweight, you add as you need as opposed to everything there for you out of the gate. you can think of sinatra as being a simple domain specific language for creating sites or apis (i use it for both).
With Sinatra you add in and with Rails you taketh away.
You can use Sinatra for the same things that you use Rails for, but typical use cases are API's, since there's a lot of stuff in Rails that you don't want to use if your main output isn't html.
The light part means: it doesn't drag a huge framework and code and complexity you don't need with it. It uses less resources than it would if it was doing that.
I would actually say that Travis CI is a Rails app, Rails is just not taking care of HTTP, but we use large parts of the Rails stack in many of our applications (Travis CI is a fully distributed app).
Our API app used to be a Rails application, but we ended up writing our own object serializers etc, so that the controllers were actually more or less just calling out to one method.
When we reworked our API, authentication, etc, we switched over to Sinatra.
When do I use Sinatra?