UIs can spawn jobs in the background, but that's an explicit thing programmer has to do, and evidently they forget all the time. It took Apple over a decade to mostly fix "beachballing" problems plaguing Finder.

Another problem that may be Cocoa-specific is that it can hook UI-changing observers to objects, and then these objects become unsafe to use in multi-threaded programs (including those background jobs you should be using!)

Yes, but the 'background threads' are usually not working on the UI.

So it's not rocket science to just coordinate access to the tree.

It'd be nice to have an architectural way of doing that, but frankly, just living with the idiom ("Don't Do This") works well, and some frameworks put in runtime checks, i.e. QT will crash I think in some cases if you try to mess with the tree on the wrong thread.

Not really UI, but wasn’t one recentish game really performant due to it using Vulkan, but in a multi-threaded way? Not sure whether it would benefit traditional UIs though.

I think when you get to rending and composting, the multithread issue gets a little bit different and possible to distribute a bit.

It's at the 'Model Tree' layer that the UI dev 'interacts with' directly that single thread is often enforced.

Multithread seems to only be reasonably possible when you have 'control' of everything and a careful approach, and when the situation calls for it.

Intensive graphics rendering is something which does deserve the GPU and multiple cores. But most "UI" as we see it shouldn't be that intensive. UI drawing is usually on the GPU but stuff like handling inputs, updating the UI tree, should be fast enough on one thread.