In order to know "what changed", you need at the very minimum to maintain a meta-state about your application state.

In most retained-mode GUIs, this meta-state is often a copy of a significant portion of your application state, but with a very different structure. To maintain the integrity of both copies, you then need a layer of events and/or listeners on top of that, with a complex and dynamic control flow.

Retained mode optimizes for display throughput, which matters a few decades ago. Immediate mode is better for latency and consistency, which are much more important now.

it's "obvious" until you learn that most games (with way higher perf requirements than anything else) are immediate mode rendered. as with everything it depends - in this case, on how much usually changes, and how nested your data is (DOM trees are O(n^3) to do proper retained mode diffing, whereas full rerendering every time is O(n))

React's reconciliation bridges this - immediate mode programming model, retained mode commit model, with key-based bailout to solve the O(n^3) problem. There are reasonable disagreements as to how necessary this is, of course.

> it's "obvious" until you learn that most games (with way higher perf requirements than anything else) are immediate mode rendered.

Games also tend to be the only/main thing running at a time and constantly update large parts of their display. This is not true for most applications.

Tracking what changed has its own complexity.

If you have transparent or moving elements you have to identify the components behind them and redraw those as well. You could use buffers for each element to avoid some of it, but then you may have to update several buffers for various changes.

If you have elements that are updated a thousand times per frame (progress bars) do you update the whole element every time, only update the affected region of it on every change or try to somehow collect changes that might affect different parts of it for a single update operation?