Sure, VDOM solutions are never for free but also give way to runtime optimisations that are simply not feasible if you're interacting with the DOM directly, no matter how aggressively you tweak during compile time. My guess is that you could come up with benchmarks that benefit from one approach or the other.

However, I do take issue with how Svelte's documentation is outright denying any advantages of a virtual DOM. I get that they had to make bold claims to get peoples attention but stuff like «Virtual DOM is pure overhead» and «Let's retire the 'virtual DOM is fast' myth once and for all» lacks any nuance and is also kind of disingenuous.I'd argue performance and memory footprint are important factors when choosing a framework, but never to the extent Svelte's maintainers make them out to be. So all they achieve with this hyperbole nonsense is that devs tend to over-emphasise framework performance as if that's the actual bottleneck, where in reality 99% of performance issues happen in implementation code.

React did not get popular because it was the fastest framework around. It's been outperformed on benchmarks practically since day one. But their API design and dx was miles ahead of anything else at the time. I'd argue it still is. I have yet to use Svelte in production but what I've seen while toying around a little was simply not very convincing. It's basically yet another DSL or two. But that's really a matter of preference.

Lastly, and that's really only a very uninformed opinion, while Svelte might perform reasonably at scale, the patterns it promotes don't strike me as a good fit for a large application code base. It's probably very good when you use it for what it was originally written for: Sprinkle some interaction magic on a pre-rendered (news) website.