Immediate mode GUIs have significant limitations. You can probably lie to your end users by saying the API is immediate mode styled, but actually retained under the hood (and I think to some degree, this already happens today with cached state), but I think that defeats the point.
1. Very complex
2. Able to use custom, complex widgets
3. High performance
4. Written very quickly with a very simple API
Those are significant pros.
There are a few serious downsides as well:
1. It is not remotely conforming to the platform's standard UI (a bit less a problem for a DAW since they all have custom GUIs and widgets anyway)
2. The font rendering is done by the GPU using cached textures, so it's more limited in terms of what you can achieve there (not so much a problem for DAWs because you don't have much text to display)
3. Power usage can be high unless you use tricks to adjust the frame rate dynamically
4. It's in C++, which can be a con for some people (although it's written in old-school C-like style)
If you can live with those, it's a great solution.
"Immediate mode" is a description of the API, not the implementation. It's not a lie to cache state under the hood. In fact it's sensible and doesn't defeat the point at all.
This is incoherent. The implementation is shaped by API limitations. Immediate mode APIs that hold data on the GPU are not immediate, they're by definition retained.
ocornut's own bulletpoints are incoherent. He can call it whatever he wants, it doesn't mean it's meaningful.
The fact that he's designed a retained mode library with an immediate mode API doesn't mean that it doesn't have literally the same limitations, because he doesn't expose the abstractions to you to actually do meaningful retained work.
I don't care what made up paradigm someone else has invented.
Anyone who was doing immediate mode graphics programming before shader based pipelines knows exactly what it is, because you would have used the APIs by standards organizations themselves.
