The rate at which you have to update, and what you have to update doesn't change between retained and immediate mode. The only difference is that, with retained mode, the library you're using has, by design, all the knowledge it needs, so it can manage all of that for you. The whole point of using immediate mode is to get rid of this black box from your program, so that you can explicitly state what you want to happen, when, and in what order. It's only "a ton of code" if you write everything from scratch, so i fail to see how that's an argument.
while (true)
{
processInput()
updateState()
paint()
}
That will kill battery unless you write code to not update until input or app state changes, in which case you're building up to your own retained-mode system.
Yes, if you were concerned about battery life, you'd typically not update until input or app state changes.
As for building up to your own retained mode system: not really, at least not in my view. Whether you update at a constant rate, or update only in response to user input (or whatever), you're still doing the key things that differentiate immediate mode-type GUIs from retained mode-type GUIs: firstly, you're regenerating the entire UI from scratch each time; and secondly, you're handling the input events while doing the regeneration.
This is what makes immediate mode-type GUIs so easy to use in many cases. You never have to make sure each widget is linked up with whatever it relates to, and you never have to ensure the widget list is kept in sync with the list of things, and so on. You're always building the widget list from the (authoritative) list of things, and processing the related input events at the same time.
Immediate mode is simply a way of designing your API so that there's no creation, destruction, callbacks, etc. It's a convenience to the programmer, because they can explicitly express what they want to happen at a given moment, and the application state is known at any given time. It's a general concept that can be applied to any code you write, and it most certainly doesn't forbid you from keeping track of dirty regions between frames, that would be ridiculous.
