There's some nuance. DOM mutations are still expensive if you interpolate reading and writing operations. The declarative paradigm allows frameworks to batch same-type operations to prevent double repaints. This is the upsell of virtual DOM vs jQuery, but it's not a benefit that is exclusive to virtual DOM.
Virtual DOM comes with a different set of trade-offs in terms of needles and haystacks. If you have lots of mutations relative to the size of the DOM, then virtual DOM overhead per mutation is relatively low. But if you're only updating a single element in a very large tree, then you are incurring a lot of overhead per mutation.
Another modern confounding factor to be aware of is that some browsers (notably Chrome) have made it so that mutations through the DOM API no longer cause a repaint to block the main thread (which is how every UI system ever should work, really). What this means is that any performance benchmark that uses JS APIs to measure UI responsiveness is going to be problematic (either by not measuring repaints correctly, or by adding a ton of confounding factors by shoving the macrotime queue of setTimeout/friends into the measurement)
Also, qualitatively, there's different levels of overhead. A repaint takes in the order of hundreds of milliseconds (i.e. it can be noticeably expensive). DOM API calls are also "expensive", but only in the order of a millisecond or so; you do want to touching the DOM unnecessarily if possible and virtual dom helps avoid silly mistakes like re-querying the DOM on every event like in the `$('.foo').on('mousemove', () => $('.bar'))` anti-pattern. Virtual DOM is "overhead" in the sense that allocating memory for a virtual DOM node is "expensive" (compared to not allocating any memory). But we're in microsecond-per-instance territory at this point. You need large haystacks with very small needles at high frequencies in a slow device to experience human-noticeable performance degradation from virtual DOM object allocation overhead.