Why not Ajax?
That strikes me as a great place to unit test. As a point of entry/egress in and out of a given domain, that's one choke point where it's nice to know your code is going to handle bad data in the best possible way. Ideally, a network hiccup or data problem won't throw the kinds of exceptions that break all the code on your page and give user feedback as appropriate. But I would emphasize live-logging validation here as a strategy first.
Semi-Agreed on the DOM Interface
All you can test for is whether something works when all the HTML is correct. You really can't make assumptions about what your code should do when the HTML is broken because validating for every little DOM operation is way too expensive. Also, breakage is typically so obvious it's a wasted effort anyway. It's better to simply have test pages full of in-production variations on fully functional widgets with automated activation of their various features. If that counts as unit testing then I guess I disagree.
Agreed on Unit Testing Data-Juggling/Data-Formatting/Logic
This is definitely the interior layer where it might make the most sense to focus on some sort of a testing strategy.
But Still Not 100% Sold on Extensive Client-Side Web Unit Testing
I'm on the fence about it primarily because it's obscenely easy to test your code before committing it and issues are typically highly visible on the client-side. If you don't get immediate visual cues you'll see problems in the console.
IMO, the critical thing is to focus on testing for how your code reacts to bad stuff from vectors you don't control like what's coming in from Ajax or JSON dropped in by the server on page load. Regression issues of the whack-a-mole bug variety where one "fix" breaks something elsewhere are something any client-side web developer should be loathe to ever allow into their code in the first place by maintaining clean separations of concerns and hand-testing the crap out of all their work in every browser supported before committing. That takes time and I'd argue time is better spent avoiding the problem in the first place than testing to see if you failed to avoid it. JS's flexibility makes it so easy to reduce complexity that I would tend to argue for automated testing only at key bottlenecks and necessarily highly complex data-handling.
In recent work with a very messy codebase that has mostly not been touched by client-side dev hands the most critical debug time-saver IMO, is first establishing a way to very rapidly rule out whether it actually is a client-side problem. If you're validating all data to and from the server and logging issues (silently in production of course) as they happen, this can be a matter of seconds rather than hours. But that's not unit testing of course, it's validation, which I would argue is more important than unit testing when you can run and diagnose your code in a live environment as easily as we can with client-side web code.
Consider a Mixed Strategy