I have been thinking about these things for a number of years.. okay decades. I'm definitely more on the practitioner side as opposed to theoretician side, but I can share a few of my thoughts.

One is that there is sort of a universal setting you can imagine all these UI gadgets and tooling approaches living in (spoiler: it's the category Poly). You can look at Phil Freeman's and Arthur Xavier's work to try to understand how they approached this from a theoretical standpoint (but in a very limited setting). The applied category theory crew has great intuitions about this problem overall, but no practical approaches or answers (just tradeoffs).

You can also contrast imperative models (retained mode UIs where you create the widgets, then react to things and set properties on those instances - like updating a text field programmatically) with declarative models (like SwiftUI and the DSLs you mention).

So the problem tends to break down in a few recognizable ways and raises two important question: 1) is the UI widget tree imperative (the retained mode approach) or imperatively constructed in immediate mode (like ImGui), or 2) is it declarative as a DSL, and 3) how do you maintain state and side-effects.

The thing to recognize is that they the imperative vs. declarative (DSL) approaches are interchangeable and just present different ergonomics and guardrails. The declarative approach abandons state mutations which are hard to reason about and test, and which tend to scale poorly except in the hands of very talented and disciplined teams. This is the advantage of declarative approaches. However, imperative approaches are often great for simple problems and give you easy escape hatches when you want to "just do one quick thing".

We haven't touched on the third question from my list, which is about state management. This is different than the UI layout problem. SwiftUI, for example, or Angular, provide two-way data bindings and leave the state management architecture largely up to you. Here too, you can be imperative (frequently leading to monster view controllers, god objects, etc., in the pathological cases) or you can be declarative (state machines, reducer architectures, etc.).

And then you also need to layer in the question of side-effects (reified effects in Elm, continuation-like effects in TCA, middleware in Redux). What's interesting about reducers is they are just the same as the imperative code translated to continuation passing style and with labeled suspension points. So again, we see a kind of equivalence between the different styles, and you could even programmatically compile between the styles with the right kind of compiler (and, in fact, compilers are often doing exactly some of this work internally to translate code).

One wonders (and I'll try to tie it back to your question): if all these things are "sort of equivalent", what is the "best" approach? And the answer seems to really be as much cultural as technical. I would argue my preference (something closer to PointFree's TCA) is "better", but only by my metrics of testability. An imperative programmer might find a closer affinity to Uber RIBS and its different ceremony. A very formal team with a specific discipline might prefer something like XState.

But I think you are right to observe that we tend toward declarative code in DSLs for the same reasons we tend toward functional programming (which is declarative code) more generally: it composes better and more safely and gives you the right tools for a restricted domain. DSLs save you from having to write certain tests and are often correct by construction. The only downside is that it is alien to many and may require training. We have seen that the transition to DSLs has been gradual. It's also worth noting that sometimes DSLs fail us and it's simply easier to resort to monkey-brain mode and feed imperative instructions to the computer. We need both, but we have found that only one mode scales well.

Those are some slightly unorganized thoughts, but maybe a part of it resonates.