I think the main reason why small things like rawJS are appealing is that a lot of devs got directly or indirectly forced into learning a framework and then got themselves burned one way or another while using it. We then developed a shared fantasy: "What if the native browser API was good enough so that we don't have to learn any fluff (frameworks, build tools, libs) to be productive? After all, other languages don't have this framework bloat problem. Let's just use this minimal lib instead."
But this is just a fantasy. Element constructions are not the problem. Updating the state and DOM is the issue. We don't do stuff like rawJS or jQuery for bigger apps because they are too low-level and they don't scale well. What we need is to operate at a higher level, not get rid of almost all of the abstractions entirely like rawJS. Have a look at https://github.com/squaresapp/rawjs-sample/blob/35939695dba6.... This is the kind of code that is meaningless to my app. It's just DOM housekeeping. The example app is small enough so that there isn't much of it: this is the only interactive bit of your demo app. But the bigger the app, the more housekeeping like this you need. Try to showcase a bigger demo app with a lot of interaction.
Now, there are specific cases where I don't want/need a framework. If I want better performance, the framework can become a hindrance (this is generally the case - when you want performance, you need to look at the lower levels). If the app is tiny, frameworks are just fluff. But for the overwhelming majority of cases (apps that are not tiny and don't need amazing performance):
As a web dev, I want to assign some object to some reference and then my app to be updated based on my state. When some event happens, I want to update some of the app state. That's it! I don't want to mix my business logic with DOM fluff. I don't need another piece of code to worry about. I want some dependency to do that for me. Is it going to happen via virtual DOM or change detection or something else? Who knows.