"Immediate mode" just describes the programming model (e.g. how the UI is described with code and how the code reacts to user input), it doesn't tell anything about how rendering happens (or really anything that happens under the hood).

It does imply to some degree that the entire geometry of the UI isn't stored in GPU memory. It's possible to store an entire UI, with text and all, in GPU memory and render it with a single call (e.g. glDrawElements).

...and those GPU buffers need to be rebuilt as soon as anything in the UI changes. An immediate mode UI could just as well track state changes and only rebuild GPU buffers if needed.

Most just don't this (and instead use dynamic buffers which are updated with new data each frame) because the state diffing would complicate the implementation and is usually "not worth it", but they still implement batching within a single frame and reduce the amount of draw calls as much as possible (for instance in Dear ImGui, there's usually one draw call per scroll/clip region so you get away with a handful or at most a few dozen draw calls even for complex UIs).

This doesn't make any sense. GPUs know nothing about declarative or imperative designs. Many immediate mode GUIs output a vertex buffer or a list of draw commands that can then be rendered anyway you choose, including having it rendered by a GPU.

Both declarative and imperative UI frameworks benefit just fine from GPU acceleration, that's orthogonal to the underlying drawing mechanism

Can you give more details on how this GPU acceleration works?

Dear-imgui, the most popular and mature immediate mode GUI library, renders with OpenGL/Vulkan/DirectX.