Gmail does work without javascript, it has long been the example I give of competent web authoring. As for when it makes sense, I suggest this guideline: if what you're building is to be a worthwhile contribution to the World-Wide Web, it should have a mode with server-rendered semantic markup behind URLs which are stable forever. Client-side rendering is an enhancement to build after that works well. Your content is more important than the custom behavior you're adding to the the browser the user already chose.
This is exactly the approach I'm doing. I'm writing the app entirely server based, just a couple of ajax do avoid loading unnecessary data at some time.
The time I finish the app, I will tweak and optimize loading either by AJAX or implement something like backbone views.
Well, for a start, when you've got a fully developed API.
We recently built a project that used a Backbone SPA for _some_ views, but was primarily server side.
Now we're building a mobile version, and having built the API in the first phase, we've got enough to go on to do it all via Backbone.
Additionally, when developing for mobile you're much more aware of bandwidth restrictions, so the ability to load only what you need becomes useful. When you're flicking through a bunch of pages that use the same view but with different data, an SPA lets you load only what you need.
Whenever you can. It allows you to animate transitions during navigation, and to give your website more of a dynamic application feel instead of a static site. If done well, you encourage deeper interaction, as navigation feels more intuitive with smooth loading performance, without a jarring page reload, and with animations indicating what's going on.
