Right -- you mentioned testing, but I'd like to hear more about benefits in your actual app. Putting something in a separate object just to make it more "testable", but without any actual benefit to, or effect on your app's behavior, strikes me as the essence of unnecessary abstraction. You can certainly test views that "know something" about the DOM without actually using the DOM as well...
4) View/Template Performance
Ok then, IE8. It has largely the same DOM performance characteristics (ie, slow) as IE7 -- and it'll be around forever, or as long as Windows XP lasts -- whichever comes first ;)
For the purposes of a web application, Rails/PHP/Python being slow matters far less than your template library being slow. They're in the backend, you can run many instances across many servers, you can cache their output, etc.
If your JS templating / View library is too slow, it means you can't use it to build the most interactive and interesting parts of your UI -- precisely the parts for which using client-side views would be most helpful.
I'm talking about even relatively simple things, like this: http://blog.documentcloud.org/blog/2011/10/entity-charts/
Better to benchmark now and find out, either way.