The issue is that any time you add another generic layer, it involves another layer of loops for "handle everything" tasks and lookups for "handle this specific thing" tasks. A native app could set a bunch of values for properties by changing them in a single function accessing a single data structure. You might have a single function that does the same thing using frameworks, but that function is potentially going to use accessor functions to reach down each layer to set those values where they matter plus could need to do a bunch of transformations as it traverses each layer (or maybe that's done on the render side).

So then you add a bunch of caching to improve these common scenarios and balloon memory usage, which was already inflated because those layers also need memory to store their data structures.

And these things get worse as they scale, so small scale tests still look snappy and hide how much things can grind to a crawl when it needs to handle the large or normal scale. Not to mention, if you don't have a speedy version to compare to, you might just think that it makes sense for this process to take a couple minutes because it has millions of things to do (despite running on hardware that can do billions of things per second).

To me performance is almost always bad engineering choices like not understanding or handling I/O.

So that means every single developer that has ever used Electron or CEF for something, has been making bad engineering choices?

You may have something there.