I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentation are seperate concerns.

A good example is a CMS/wordpress (which as we know makes up a third of the internet or something): Editors are concerned with content, themes are concerned with presentation, plugins are concerned with behaviour.

Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. If it does, its a different separation like M-V-C. I think all the successful user interface things introduced in the last few years are going for an all in one code approach for good reason: SwiftUI, Flutter, Jetpack Compose, React Native... I may be a little mobile focused?

The options that ios/mac os/android offered for a while to create UI structure seperate from code where not very popular with developers which often preferred to construct and modify the entire UI tree with code "manually".

What‘s the state of the art in windows and linux UI programming?

I agree that a UI is well expressed as a tree, for the sake of accessibility and other reasons. I don‘t see why there is any reason to seperate the declaration of that tree from the application code. The flutter approach is bad, but all established desktop and mobile UI frameworks provide accessibility support as good or better than HTML.

In fact, HTML is ill equipped to express capital A Applications in an accessible form and needs ARIA as a bandaid to make it work.

The application runtime knows about the UI tree by the time the app is running and can tell accessibility tools about it. Wether you write it down explicitly or not doesn‘t matter. It only matters for web "pages" which are original not something that is running at all.

> HTML defines semantic structure of UI

The problem I have with HTML is that it's only really any good at defining the semantic structure of a document, particularly the type of thing you might produce with a word processor. Half the stuff on a modern webpage—even those you'd still call documents rather than apps—can only really convey meaning via visual layout, and so break down when divorced from CSS/JS.

For example: I'm a big fan of reader mode in browsers, but so often they're tripped up by basic UI affordances like menus and image galleries. The renderer has to guess at what's content and what isn't, so half the time any sort of "widget" is rendered as a crappy-looking vertical list. Sure, that's technically what a menu or gallery is at its most basic level, but surely we can do better?

There probably are sensible defaults you can already follow—representing a menu as a <nav> containing <li>s, say. But it would be much easier if there was a <nav-item> tag. A <nav-item> inside a <nav> would semantically be a menu in the same way that <li> inside <ol> is semantically an ordered list—you don't need any CSS to render that in a sensible way.

Same goes for galleries; if we had a <gallery> tag that could contain <main-image> and <thumbnail>s, you'd still be able to do custom layout with CSS if you needed to, but at the base level you could sensibly render it with just the markup itself.

I dunno, I just find it weird that we added all these new tags for HTML5 years ago then just stopped bothering. I mean when was the last time a HTML element with behaviour was added?

In an ideal world a reader mode could be expanded to a "reader-friendly page mode" wherein the page still looked approximately like the normal webpage, just without all the user-hostile shit. Of course, that's usually diametrically opposed to the financial incentives of running a website, but it's nice to think about.