If you can get away with storing your data in the DOM, then go ahead. But this technique is mostly applicable to low-interactivity views (see the view layer overview chapter) - once you start displaying the same data in multiple locations, having your data tied to the DOM structure and state goes from being a easy technique to a complication. Hence I don't really consider storing data in the DOM as a single page app technique as much as an easy way to do low-end interactive components.
I have never been a big fan of "easy" data binding, and totally agree that data is not to be stored in the html. Same reason why you don't use your kitchen table as the pantry...
I'd say databinding is useful for smaller convenience plugins, not for the architecture of larger JavaScript applications. From my quick skim this book is spot on.
Sort of? I mean, if you're using models and collections to store _model and collection_ state, then essentially yes, you'll probably have a global variable that namespaces the state of data in your application (or closure-wrapped modules, as the author suggests).
At a certain point (and fairly early, really) keeping the state of an interactive application as HTML nodes is not what I want.
I'm not fond of the way Backbone.js works. It solves none of the hard problems of making an SPA. (AngularJS is guilty of this too, albeit from a different angle.)