The vast majority of games use simple GUIs where it won't matter. But if you have a complex or large GUI, you will be eating up significantly more CPU cycles.
Once you have such a system it doesn't matter whether the higher level parts follow the immediate-mode or non-immediate-mode philosophy, or if the scene graph itself is rebuilt each frame or not, just the render state changes and draw-call overhead will kill performance as soon as you have a few hundred UI elements on screen.
Dear Imgui builds flat vertex buffers and a very simple command list where each command is basically 'please render this range of vertices with this scissor rect', and as I wrote above, generates about 1 draw call per window. Only a new clip-rect (e.g. a scrolling text frame) requires a new draw call. As an example, in my 8-bit emulator, the entire debugging UI, with all windows open (12 windows with a lot of scrollable text, buttons, lists etc...) costs 16 draw calls.
Just to take "simple" text rendering... When you have just ASCII text rendered with monospace font then it probably OK to do its full layout on each render run - that's really simple. But if you need to render, say, HN page then you'd better compute once and cache glyph positions. And other objects too that need calculations: gradients, tesselated shapes, etc.
Check this: http://sciter.com/sciter-and-directx/ That's relatively simple UI rendered directly into DirectX as a batch of precomputed meshes.
Ideally you should be able to take best of two worlds: immediate mode graphics and declarative one.
Also, the optimization bottleneck nowadays is mostly programmer/brain time, so having a ten-fold productivity improvements means you can actually create more/better tooling and that has very direct consequence on your software performance. The reality with toolkits like QT is that people write very little amount of tooling with it, because it is so tedious. The cost of that are lost opportunity in improving a game engine and its performances.
It's funny that you mention this because I remember trying to utilize DirectX RM (retained mode) for a game in late 90s. Even without taking the performance into account (one could say that the implementation was not very optimal) it was a major pain to do anything. One thing I remember vividly: our explosions were static meshes containing all frames of animation and were animated through toggling visibility of different nodes. Luckily that game had been killed by publisher and I did not have to suffer through optimizing its performance.