With more complex project there’s benefits of having purely updatable components, the support of just native JS without quirks and knowing exactly what’s happening and when without black magic.
But if course it always depends on the project which way is better.
With more complex projects, anything that isn't a declarative becomes painful to manage. In complex web-apps, the benefits of using a VDOM over imperative libraries like this far outweigh the extra O(N) memory consumption.
> this far outweigh the extra O(N) memory consumption.
Calculating memory overhead for vdom is actually pretty hard. With imperative code there will be several different code paths for initial rendering, updates and removal, and depending on the ratio of component instances per component type in the application, vdom can consume less memory because there will be less code and less code means that there will be less internal data for JIT.
Also, if it is a highly dynamic application with high ratio of dynamic bindings per DOM element, and imperative library will wire all dependencies with direct DOM bindings in a huge dependency graph, it is much more likely that this graph will consume more memory, especially in use cases like filtering large lists.
But if course it always depends on the project which way is better.