I mean, React is essentially a hack to get an immediate mode API on top of a retain mode platform (DOM), because the immediate mode API scales better to handle complex state.
I'd push that yes, you do have to maintain your state externally in an immediate mode UI, but when you have a lot of "state" that's really just a function of other state, that's exactly what you want.
The interesting thing about React is actually that it encapsulates a lot of state retention inside an immediate-style API. state/setState (and now state hooks) are the unsung heroes of the ecosystem, because they let you focus on only the business-relevant global state, making it natural for a dropdown menu to handle its own open/closed state and insulate its user from that complexity. And many intermediate mode libraries gloss over this need, so you have to track much more state than you’d like.
It’s a fascinating hybrid - rather than “BYO State” where the library does nothing but layout and draw, or “BYO hierarchy” where you need to retain instantiated components, React is “hierarchy tracking included” - all the benefits of persistent components, but tracked by the renderer rather than the caller. It’s an evolutionary step that I think desktop programming would do well to adopt and continue to iterate on.
I'd push that yes, you do have to maintain your state externally in an immediate mode UI, but when you have a lot of "state" that's really just a function of other state, that's exactly what you want.