Lauren,
Sadly, I think that even many in the HTML5 community lost sight of the real goal for DOM. I've described DOM to clients as a mechanism whereby different languages communicated with the conceptual layer of the HTML page. XPath (and its derivatives) could have readily supplanted it, as JSONiq, XQIB and Saxon-CE all illustrate quite well, save for a couple of engineering (and political) problems.
The engineering problem was the need to start rendering a document before it had been fully loaded, which ironically would have been resolved simply by treating a sequence of nodes as a valid HTML input, instituting a rule that if an element with the same id was encountered in the stream it would replace any previous node with that id, and eliminating the idea that a document "ends". It would have effectively annulled the need for AJAX, and would have significantly reduced the need for JavaScript in the first place. A "new" document would then simply have been accomplished by passing a <page> element to the client, layout containment would happen either by syntactic containment or by reference, and script bindings on new elements would only be enforced when such an element was created or replaced.
The political problem was the need for DOM in the first place. DOM was seen by many as a way to make HTML understandable to programmers who were used to working with imperative languages, and as such it was an adoption issue.
I see a lot of that thinking in HTML5, one of the reasons I think that the language is ultimately a failure. When HTML 4 was standardized, the need for a consistent set of features was very high, and so the incorporation of standard tags that performed core functions declarative made sense. In HTML 5, the need was no longer really there, while the need for providing a consistent mechanism for extensibility was critical - JavaScript and jQuery have effectively become sufficiently fast and powerful that adding new functionality into the browser via tags is now feasible. Indeed it's at the heart of every JavaScript binding of a <div> or <span> element to turn those generic block and line regions into containers for behavior. Instead, there were bitter arguments about the utility of <hgroup> or <nav>, whereas things that would have had far more use - such as a <linkBlock> element that would have been a container for search result link+metadata - were ignored because they didn't fit the 1990s retro vision of what the browser should be that WHATWG arbitrarily chose.
Now, after the fact, things like Web Components and Shadow Trees seem to finally be making their way into the specification, though I fear that much like XBL before them, these standards will be met with a cold reception by the browser vendors. I hope I'm wrong - I think that in many respects it will be experimentation about the nature of the HTML standard itself that will drive the evolution of the web.
