* Do not store state in the DOM. You'll live to regret it when you need to represent the same model in more than one place at once, or refactor your UI.
* Events are the way to go, when connecting changes in the model to updates in the view. Ideally, models know nothing about what UI happens to be on the screen at any given moment.
* If you're going to be doing interesting business logic in the client, it helps to have collections (in this case, Backbone.Collection) with a richer API than JS arrays: filter, any, map, reduce, reject, include, invoke...
* Lots of little testable JS files for development, one minified gzipped file for production.
The one point I'm in disagreement with is: "Keep your models as simple as possible". In my opinion, client-side models really shine when they contain a large part of your important JS business logic, and you can use the same models in different situations to provide access-control, URL generation, data munging, etc.
For example, here's a list of some of the methods we have on a Backbone.Model called "Document": viewerUrl, publishedUrl, canonicalId, openViewer, openText, openPdf, allowedToEdit(account), checkAllowedToEdit(account, message), checkBusy, notes, uniqueEntities, isPending, isPublic, isPublished.