Immediate mode GUI makes perfect sense for applications that repaint themselves all the time 60 (or more) times per second, as they're already doing the work and there's little overhead added by handling such GUI. I can deal with 3D editor working this way, but I don't think I would be very happy if my e-mail client did.

That's just an implementation detail. The main benefits of an immediate mode UI is the API for using it. There's no reason that the loop has to run at 60 FPS. It could even be event-based, so it only updates when the user does something, for example.

Yes and no. That API makes certain approaches easier and other harder. Even if you manage to render only the changed parts of the screen, you still execute all your UI logic all the time so the renderer can be aware of what changed in the first place. Also, more involved stuff like animations become much more complex once you go event-based, to the point where retained mode UI may end up being a better choice from the API perspective. It all depends on what exactly you're implementing, and games often are a natural fit for immediate mode as they usually allow to keep it simple with no real downsides.

I don’t have much understanding of the internals of the immediate mode renderers, but I think there are optimisations to only redraw regions where component inputs have changed.

You typically have to implement those optimizations yourself, and most people don’t. It’s outside the scope of the renderer in most cases for it to decide what should or should not be rendered. As a result, immediate mode GUI, while fast to develop, typically really kills a battery life on mobile.