結論
config.serve_static_assets = true
config.static_cache_control = "public, max-age=604800"
config.assets.compress = true
config.assets.compile = true
config.assets.digest = true
staging.rb も同様の設定に。
蛇足
Job-Hub ではキャッシュの保持期間は7日間にしていますが、もっと長くてもいいかも。
サンプルでは一年間（31536000）とかもよく見かけます。
config.assets.digest = true になっていれば assets なファイルには asset pipeline により常に MD5 な文字列が付加されるので、「キャッシュのせいで更新したはずのファイルが古いまま」ってのが原理的に起きないからですね。
逆に言うと、ブラウザのキャッシュを使用する場合はこの設定は事実上必須とも言えます。
この機能を無効にする人はあまりいないとは思いますが。
あと、そもそもこの設定は assets なファイルのオリジンサーバが rails 本体の場合のみ意味を持ちます。
heroku でホストしてたら heroku がオリジンサーバ。
asset_sync を使って S3 に assets なファイルを流している場合、S3 がオリジンサーバなので、この設定は意味がありません（やっても害はないと思うけど）。
この記事の内容はタイトルと異なり heroku 限定ではないのですが、IaaS なりを使っているならそもそも Apache や nginx などのリバースプロキシがいるのが一般的だと思うので、そちらで対処するようにした方が良いと思います。
CDNを使っている場合
CloudFront のような CDN を使用する場合、キャッシュの保持期間は CDN 側で TTL 設定を行うか、オリジンサーバのキャッシュコントロールヘッダに従うかの二択になっていることが多いと思います。
TTL で対応しても別にいいとは思うんですが、本番とステージング環境みたいに数が増えると CDN 側で設定はあまりやりたくないなーというのが正直なところです。
単にめんどくさいってだけの話ですが。
ちなみに CloudFront のキャッシュ時間が設定値によりどう変わるかは、以下のページが参考になります。
CloudFrontのキャッシュ時間(TTL)はどの程度なのか