Well, if they didn't bake LookAndFeel in from the start, all of the work would fall on the application developer to manage these things. Having had to look into doing this the way they chose is the best way, what most people have a problem with is the UI didn't look fully native on most platforms for a long time.
One is that if the look and feel of an app is native to the platform then it can lean on a design language that users of the platform assume, which makes it easier for those users to understand how to use the UI. Affordances look and act the way they expect, which reduces the time and effort it takes them to learn a UI.
Another reason to prefer it is that a UI that doesn't look native stands out as different. Noticeable differences are information. If something in a UI gets your attention, it should be because it's telling you something meaningful. Gratuitous differences from the platform's UI standard are not telling you anything meaningful, so they're just noise.
A third reason is that native platforms provide their native looks and feels through standard frameworks that also provide substantial whole-system features beyond just making things look alike. For example, Mac users can rely on a common set of keystrokes to do the same things across almost all applications (and the exceptions are badly behaved). UIs built without the platform frameworks must either recapitulate all of these platform-wide conventions or just ignore them. Commonly, they just ignore them, which means that conventions that users take for granted stop working in some apps for no good reason.
Also back then browser apps were a novelty instead of how most people interact with computers most of the time, and thus anything that wasn't using a native toolkit stood out pretty bad. A few apps like MP3 players used it for their advantage, but I remember those as being mostly a confusing mess.
More importantly, font rendering has improved incredibly and most rendering looks the same across toolkits in the same desktop environment. Back then some toolkits supported antialiasing, some did not, some had godawful rendering that looked like crap, some couldn't render certain symbols correctly, some didn't have good hinting for LCDs, etc.
The reality is that very slowly most UI paradigms have converged into a few well-established patterns (no more multiple-window apps, no more focus-follows-mouse, no more deep right-clicked context menus, etc). So now the styling differences are more apparent but most UIs are functionally the same nowadays. The same could not be said 15 years.
We have come a long way; despite the different looks, the feel is much more uniform, and there's a better understanding of what makes for good UIs.
As I write this, I'm frankly quite thankful that we have reached this state of good-enoughness. Spending hours looking into GTK themes and different fonts was fun, but in a frustrating way in which no exact font-icon-theme combination was entirely satisfactory.
Most consumer applications are now webapps or electron apps. From accounting software to music players, they are not native.
If someone botheres to make a desktop app, you either have proffeshionals tools or resource intensive applications like Adobe Photoshop, Blender3D, 3Dmax, IntelliJ IDE's and Games. None of them look native either!
Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.
Well, unless you're talking open source tools and/or everythign within the sphere of desktop productivity . Then invariably your "consumer" desktop apps of choice are some mixture of GTK2/3, Qt, Swing, WxWidgets......
Granted, the different GUI libraries and applications using them tend to have _slight_ inconsistencies (GNOME 3 / GTK3 window titles versus everything else's window titles), but for the most part they're consistently themed, they render quickly, they behave the same way with the clipboard, mouse interactions, element focusing, keyboard shortcuts, accessibility functions......
So I have open right now LibreOffice Writer, Firefox, Evolution, many gnome-terminals, Transmission BT client, GNOME Files, GNOME Boxes... all of which look the same and there's no cognitive load spent switching between them, because they behave the same and look the same.
I can open up Inkscape and GIMP and Evince and KeePassXC and VLC and retain that experience.
Meanwhile, whilst still my IDE of choice, my PyCharm (so, JetBrains) IDE windows do whatever the hell they want (STOP STEALING FOCUS!!!), glitch out rendering, look completely different. And Spotify - gets all its points docked just for how it handles tabbing through UI elements. ("No, I don't want to tab through ALL of the Discover page, I want tab to cycle through the different UI elements, preferably not taking a painfully long time to reach "search".... Ugh fine, CONTRIBUTE TO MY CARPAL TUNNEL THEN!!!)
"Native" (as in, "consistent experience across the whole suite of desktop applications") toolkits still make it way easier for _developers_ to design applications consistent with the rest of the system.
Android and iOS UI toolkits serve same useful purpose. I tend to find that apps that are just a reactive web framework in a fullscreen frame are pretty painful to use. Like, wtf are you doing when I hit back!??? Why is this full screen splash form with two text boxes SCROLLING when I touch it???
tl;dr of my rant: Goddamn people stop trying to make your applications look the same on every device and let me use it how I like on MY device, for the same of a) my wrists and b) my attention deficit brain
There were also some really good ideas that I wish had caught on (I was a huge fan of focus-follows-mouse and I still use the X select-into-clipboard), but the general uniformity of UI patters nowadays is very much calming.
Main benefit to me is deflecting spurious input. All that Drive By Management.
Instead of explaining the history of ergonomics, the philosophy of ethnography, and our reams of data from usability testing, I'd just point at Apple's Human Interface Guidelines.
Like name dropping Aristotle in debate class.
More serious actors will try harder, lean in.
I guess what I'm alluding to is something like CSS for desktop apps. I tried to tweak stock L&F a few times (not my choice) and I mostly failed.
Back in the day, there was a guy, Sven?, that crafted amazing L&Fs. I dimly recall he had one that was easily customized.
JavaFX supports CSS styling.
I just spotted JavaFX Script. Huh. This is almost directionally correct. So of course it got killed.
If you're curious what The Correct Answer™ is, imagine VRML-97 reimplemented using JavaFX Script like syntax.
Its wiki has a link to the Curl (programming language). That syntax is also directionally correct. But is also missing most of VRML's semantics.
There's also a link to the F3 programming language, aka "form fits function". Great slogan. Alas. Looks like a misunderstanding of Conal Elliot's Fran functional reactive programming language.
Oh well.
Thanks for the tip. JavaFX's Script w/ CSS was about 1/2 the solution. Maybe someday someone will loop back and harvest the good bits.
[1] https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...
I don't think Swing's MVC strategy worked out. It was worth trying. But maybe 40%-50% of the framework could be safely removed.
Some kind of DSL would be nice. JavaFX ain't it. In my own noodling, Swing's UI component hierarchy needed to be refactored to be fully composable. By the time I created enough shims to make Swing truly composable, I wish I'd started from scratch. (I haven't done Swing work in ages, so maybe this happened.)
An event loop is the biggest thing missing from Swing and other UI toolkits of that era. Meaning all modifications are handled by the framework, no client code (or non event loop threads) can modify the UI. My bestie George Smith's Juipeter (?) took the Win32 API approach, preserving the Swing API and all dispatch was handled under the hood. This is kinda how a browser's event loop is implemented. I much prefer an exposed event loop and Command objects. (It's easier to stepwise debug. Every desktop app I've ever created also had Undo/Redo; so you're gonna do Command objects one way or another.) And then make the framework pretty with some kind of DSL over the top.
Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. Maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.)
Edit: I didn't mention AWT/Swing layout managers. Just peeked at Google/JetBrains Compose. Meh. I like that it uses Kotlin; less syntactic vinegar than Java. Alas, Compose repeats the mistake of not separating out the layout code. After doing way too much layout code -- some Australians did a hysterical GridBagLayout rage meme video, back in the day -- The Correct Answer[tm] is custom layout managers. Still include some stock managers in the JDK. And make the layout hooks API easier to implement and debug.