It doesn't make much sense to talk about Windows native GUI these days. There's no such thing anymore. Win32 is no longer viable due to using controls and APIs that haven't been updated for years (decades?), ropey support for hidpi displays and other basics. WinUI, the official replacement, has problems and isn't used by large parts of Windows itself anyway.
That's OK though. If you look at this thread, you can see there's been a shift in what people mean when they say "native". It used to be well defined: Win32 on Windows, Cocoa on OS X/iOS, GTK or Qt on Linux, app written in a C-derived language. Nowadays people are using it to mean "not web".
Why has this occurred, well, most people don't really care what exact libraries or languages an app uses. What they care about is the user experience. People are using the word native to mean stuff like, works offline, works with files, isn't too laggy, consumes reasonable amounts of RAM, integrates well with the OS. And above all - uses a sophisticated GUI toolkit. A big part of the native vs web experience gap is that although HTML has a lot of styling functionality it's a seriously impoverished UI toolkit, barely reaching Win 3.1 standards out of the box. So people roll their own widget toolkits that they layer on top, but none of them are all that good and the modern culture of conflating widget toolkits with design systems means they are constantly being tossed out and redone from scratch (this isn't unique to the web, Jetpack Compose has the same issue).
The result is that many widgets taken for granted by Windows 95 users like splitters, menu bars, status bars, pervasive keyboard accelerators, virtualized and editable table views, tree views, customizable toolbars, draggable tabs, floating tool windows etc are just gone and power users are the first to notice this.
You can therefore satisfy people's desire for native apps by providing that sort of UX regardless of what actual tools you use to do so.