Sadly there weren't more examples and that I didn't address every piece of the puzzle here! I do hope that despite this, you were able to take away something useful from reading the article.
On overengineered, why not have a look at the value of each part of the structure described and remove what is not providing value? We found that each part was valuable to us.
On asynchronous work - I shied away from it since it's such a big topic. If it helps, our most complicated interaction was three concurrent asynchronous calls. We wrote a small state machine that was notified of the result of each call and managed the complexity of deciding what to do.
On the DOM, it would seem that the DOM bit left too much room for interpretation. Unless we had to trade of simplicity for performance, we always used jQuery to access the DOM and do XHR. We certainly appreciate and even take for granted the safety that such a library provides. The point was more about reducing the surface area of the application code that interacts with the DOM, for reducing complexity and having a well known part that is good at working with the DOM. And anyway, we never did it - which says something too.