While each use case is different, I'd like to clarify a few things in my OP.
DOM reuse is not the same thing moving a DOM subtree to a different place. DOM reuse is e.g. getting an already-rendered table row, binding a new value to it, and modifying only the DOM properties in the complex DOM structure that actually did change. E.g. you modify only an Element.text deep in the first column, and a few other values in the other columns. Or maybe you need to do more, but all you do is delta. You don't just annotate a DOM structure with a key at row level, as it is closer to a hash of the DOM, not speaking of the data-dependent event handlers.
Calculating the DOM (virtual or not) is expensive, compared to not calculating at all. Creating a virtual DOM structure and not using it afterward creates GC pressure, compared to not creating at all. We are talking about optimizations in the millisecond range. A large table with complex components inside will reveal the impacts of these small things.
DOM coordination is not just making the DOM writes in one go. Complex components like to interact with each other, depending on their position and size on their page, and the changes in the underlying structure. They read calculated style values, and act upon those values, sometimes causing reflows. And if such things happen at scale, forced reflows may cripple the performance, and coordinating such changes may be more crucial than the framework you are choosing.
I am sure that people who are familiar with React may have their way get these stuff. I have looked at it, and I haven't seen it to happen automatically, while with Angular.dart, I get it without effort.