For an individual developer it is not obvious how you should structure your usage of the DOM API to avoid the performance potholes and other problems. Even a team of experts in the DOM will sometimes take shortcuts or one expert's technique doesn't play nicely with another's.
Some parts of the DOM are extremely slow if the API is used naturally, and obvious usage of the API has other side-effect penalties (e.g. stored state, difficult component destruction, or reference loops causing memory blowouts).
So the vast majority of developers use the native DOM in such a way that the page is slow and buggy.
React et al provide a clean API that avoids the worst performance problems, while providing a framework that steers a team towards good practices, so the average developer can be productive.
The framework has a bunch of extra overhead, but the overhead is far less than the average overhead of not using the framework.
I hope you read the original article, that clearly lays out the (non) optimizations being done in VDOM.
In any compute environment, doing more than necessary spins CPU cycles wastefully. I believe the optimizations you speak of try to limit this work to the least possible, by telling on the framework's Dev world. But this is surprisingly easy to achieve without frameworks, see [1] and [2]
The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)