Static Cache Control affects the http headers for Cache-Control. As in, the server suggests to intermediate caches that the max-age=3600.
Varnish, Rack-Cache, Squid and others actively cache generated content on the server. Database calls are expensive and, even when a request doesn't make a call to the db, the less infrastructure the request has to go through, generally the faster it will be.
Rack::Cache is rack middleware that supports HTTP standards compliant caching. Their FAQ page has some good information about it's pros and cons over other caching solutions. Here's a question comparing rack::cache to varnish on heroku. Rails also has ActiveSupport::Cache which handles fragment and page caching. I'm not sure what the differences are, but both are included in Rails by default. I had said earlier that rack::cache wasn't default, but I was wrong.
Varnish, Squid, and others exist outside the Rails stack in front of the webserver(eg Apache/Nginx/etc) as a separate process. They are highly configurable, application independent, and have some advanced features (such as Squid's ACL's). Varnish and others have the benefit of minimizing the infrastructure a request has to go through to get served. If it's fresh, the request hits Varnish and immediately returns to the client. This probably has the most benefit for high-traffic sites and might be overkill for smaller apps.
Here's an article on heroku detailing the use of rack::cache in Rails3. There are also some good railscasts on doing page/fragment caching in-app and on using memcached as a backend(which is very important). For varnish and others, you can start with this tutorial on varnish's site.