I think the arguments that "well, games redraw the HUD every frame and it's fine, so why is recreating the UI every frame a problem?" are misunderstanding the problem. HUDs usually don't have much layout to do: in CSS terms, everything is absolutely positioned. Designers usually create HUDs visually using Flash or similar, so the layout ends up being trivial since, in effect, a human has already manually calculated the positions of every widget. For a programmatically-created GUI, though, there is actually layout to perform, usually via a flexbox-like model but sometimes via a constraint solving system (which makes the time complexity go way up). For this to be efficient you need a way to cache the results of layout so that you only recompute them from frame to frame when needed. This caching is precisely what a retained mode UI is.
For those who think that layout is always fast enough to never be a performance problem, try writing a flexbox UI in your browser, then open the dev tools, resize the window (which will trigger a full relayout if you don't have any explicit widths in there) and see how long the layout takes. It often eats up the time budgets of multiple frames (and this is not just browsers being slow--the complexity is inherent).
This is not to say IMGUI is bad, mind you! It's a great solution for debug overlays, which is what it was originally designed for, because of how simple it is. Just don't overstate its benefits: retained mode UIs exist for a reason.