In other words, starting out with a browser that can render HTML and CSS, and then adding an API like document.write() is a huge hack.
Exposing the entire rendering engine with a textual interface is hacky. For one, the lack of escaping makes security bugs the default (somewhat fixed with template strings in ES6). It's also really hard to reason about performance, because you don't know when layout changes are triggered and so forth.
The whole "virtual DOM" thing is an example of fixing the flaws in this API.
But on the other hand, it's sort of "simple" in that you don't have to learn as much to use it, and it gives you the POSSIBILITY of doing everything dynamically.
[1] NOTE: There are 2 distinct points in the essay. One is that "It is better to get half of the right thing available so that it spreads like a virus." That is, ship first, and then evolve the software.
The other is whether you should expose the implementation details of the underlying platform, or if you should wrap it up in a "nice" interface. JavaScript does the former.
Also, neither of these points is "crappy software wins", which the title seems to imply. It's more subtle than that.
It is only now getting such (basic) language features as variables and constants being lexically scoped by default, a generic flow control primitive (async/await + exceptions which is almost, but not quite, as powerful as call/cc), as well as useful features such as multiline/template strings, proper classes, symbols, a shorter lambda syntax, and dedicated hashmap/set containers.
JavaScript is the quintessential example of why Worse is Better.
PS: even though CSS was first proposed in 1994, the availability of JavaScript and document.write() in browsers, as well as its use on the web predate the adoption of CSS by several years.
The alternative to JavaScript -- Scheme -- imposes far less cognitive overhead than does JavaScript, AFAIC.
While the arguments here have some validity, I think a more important reason for the triumph of worse-is-better is human cognitive overhead. The correct solution being more complex requires more cognitive overhead to support, maintain, port, and implement when new implementations are needed.
Yet another reason is probably political. Correct solutions are harder to develop, so they are often developed by commercial entities and subject to restrictive licenses. Free software has less resources, so tends toward the New Jersey approach. It's hard to compete with free.