I don't think that's a great explanation of the concept of VDOM. For example, SolidJS looks a lot like the example given, and it also arguably returns an object that represents how the page looks, but it didn't use a virtual DOM under the hood.
I think it's easier to think of virtual DOM implementations as doing two things: (1) describing the desired state of the DOM in some sort of structure, and then (2) diffing that structure against the actual DOM in order to make the changes. The key part is that the virtual DOM implementation does the diffing itself in order to make the changes itself.
This is similar to your example, in that you have generated the desired tree and are rendering it in the right place. However, it is different, because the browser will not do a fine-grained diff of all the elements, it's just going to replace them with the new elements that you've given it. This works fairly well if you're trying to replace a large chunk of elements with a new set of elements, but it has problems if you just want to make smaller modifications.
For example, consider some JSX for an arbitrary framework that looks something like this:
function MyInput({ isGreen }) {
return
}
When `isGreen` changes, we want to update the current value of the DOM with the new version of MyInput, which should just be the same thing with the class changed. The naive (although often simplest and most practical) solution would be to just replace the contents of the element with the return value of MyInput - i.e. replace the input with a new copy, just with the class name changed. The problem comes when a person is typing into the input - if we replace it completely, the use will lose everything they've already written.
The VDOM solution is, as I said, to (1) generate, but then (2) to diff. So if the current state is an input with a "text-green" class, and the desired state is an input without this class, it would work recursively: First, is there an element? Second, does the element have the right tag name? Third, for each attribute on the two elements, do they have the same values? Etc. And every time there's a change, it will make the smallest change possible to ensure the current state becomes the same as the desired state. Here, that means removing the class name, but leaving the rest of the input as it is (i.e. with any input from the user left alone).
The third option here is what frameworks like Svelte and SolidJS do: they skip the part of the process where you generate a new desired DOM, and jump straight to the diffing. That is to say, when you create a component, inside that component will be event listeners for each part of the component that needs to change (and only those parts). This listen to changes in the props and state and then change only those parts of the DOM that need to change. That way, you don't need to go through the entire DOM, iterating through all those nodes that stayed the same just to find the class that needs to be updated. Instead, you just directly update the class.