I think the line's a lot more blurry than you make it out to be.
Not only are Electron apps often visually and functionally indistinguishable from "native" applications on their respective platforms, but there are also varying degrees of integration with the underlying platform you can have within Electron apps.
For example, Electron supports including native modules which have to be compiled for a specific platform. How many of those would an Electron app have to use before it's considered "native"? Or what about an app like Spotify, which only uses a web view for certain components of the UI and everything else is written in C/C++? Does merely using an interpreted language like JS or Python anywhere in your app mean it's no longer native?
Also, keep in mind that this blog post was written for Postman's users, it's not a technical write up. Postman's users may be more technical than most, but they still shouldn't have to know or care what underlying technology was used to build Postman's desktop apps. From their perspective calling them "native" apps is perfectly accurate, as they behave as native apps in every respect.
Electron apps are most certainly not functionally indistinguishable from native apps. They are always much larger and always seem to consume orders of magnitude more resources (memory, CPU.) If despotify still worked I would absolutely use that instead of the slow, buggy webview based official client.
People want native apps because they don't want the cooling/memory/power consumption from the web, as well as their delay tolerance and consistent UI. Electron can only provide the second (and sometimes the third.)
Performance is a property of an application as a whole, not just the framework it's built on.
While you can certainly argue that apps which use webviews are slower on average than their native counterparts; Electron-based apps aren't necessarily always going to be slow; and native apps aren't necessarily always going to be fast.
Therefore, since a user cannot conclude that an app is "not native" merely by observing its performance, Electron apps cannot be said to be functionally distinguishable from native apps merely because they're slower, on average, than other applications.
People conclude things based on their experience using them.
There are a lot of bloated feeling electron apps out there that are popular right now, which leads to people concluding (not incorrectly) that electron apps tend to be slower than native ones based on their experience.
Agreed. However, perceptions change as technology improves and overall the arc of software tools has been towards higher level abstractions unless absolutely required to go deeper.
That's a valid concern and I believe all developers who are working on the platform will address this. If memory/power consumption on laptops was so draining just because something was in HTML/CSS/JS, I believe people would have stopped using browsers or probably just stuck to 1-tab per browser.
Not only are Electron apps often visually and functionally indistinguishable from "native" applications on their respective platforms, but there are also varying degrees of integration with the underlying platform you can have within Electron apps.
For example, Electron supports including native modules which have to be compiled for a specific platform. How many of those would an Electron app have to use before it's considered "native"? Or what about an app like Spotify, which only uses a web view for certain components of the UI and everything else is written in C/C++? Does merely using an interpreted language like JS or Python anywhere in your app mean it's no longer native?
Also, keep in mind that this blog post was written for Postman's users, it's not a technical write up. Postman's users may be more technical than most, but they still shouldn't have to know or care what underlying technology was used to build Postman's desktop apps. From their perspective calling them "native" apps is perfectly accurate, as they behave as native apps in every respect.