None of these limitations have anything to do with an imgui frontend api though.
The common misconception is that immediate mode UIs don't persist state between frames, but they absolutely do (it's just hidden from the API user). The 'immediate mode idea' is only about the public API, not the internal implementation (e.g. internally there could even be a traditional retained mode widget tree that's only modified, but not rebuilt each frame).
I'm talking about having two labels in the center of the screen, making them full width, making the text word wrap, and having each label flow properly when resizing the window. That requires calculating word wrap for each label plus knowing where labels visually higher on the y-axis have decided to place themselves after considering word wrapping. Labels beneath other labels should get pushed downward when word wrapping occurs.
That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
TFA demonstrates this exact functionality without "recreating retained mode". Check out the "Layout" section and note that the button is shrunk to the label, all of which is centered. The layout engine becomes an emergent property of the widgets rather than an algorithm evaluating a tree. Here, the code is the tree.
The purpose of an IMGUI is to handle whatever data retention will simplify user's life. If you want to extend the IMGUI in some case it's perfectly adequate to do some that work yourself. Ideally the IMGUI infrastructure would make it as painless as possible.