For example, on my 5 years old laptop with integrated AMD GPU, windows 10 calculator in default state uses 33 MB system RAM, 9.6 MB dedicated VRAM. Maximized to FullHD screen, same app uses 36 MB system RAM, 13 MB dedicated VRAM. Maybe the OS counts VRAM as active private working set, maybe the app uses more than 1 buffer.
Regardless of the reason, it’s IMO unrealistic to expect a modern GUI app to consume less memory than required for the frame buffer for its window.
Not really true. Even machines with integrated graphics in Windows aren't truly using a fully shared memory pool. Usually the hardware reserves a chunk of the system memory for the iGPU.
Video games are the same (mostly) - everything is rendered in screen space for performance reasons, it's very, very rare, that you would render something into a temporary buffer then composite it on top of the rest of the scene - you would need exceptional reasons for that.
Maybe it's time to get back to the olden days of display servers - where applications would push a list of render commands to the 'display server', which would consist of rendering primitives, which would then take these commands and construct the whole UI on the screen, without the intermediate steps of each app drawing into its own little buffer.
You could always fall back to drawing your own applciations, then asking the display server to composite that, but that would pretty much be the exception, not the norm.
Imagine you have 3 windows visible at the same time: a videogame rendering at the refresh rate of the display 144 Hz, a video player rendering frames at 30 Hz, and a text editor rendering blinking cursor at 2 Hz. Because the videogame wants to deliver frames at 144 Hz, the desktop compositor has to deliver the entire desktop at 144 Hz. Asking the video player and especially the text editor to also deliver frames at that frequency would be wasteful. Irrelevant for desktops with fast discrete GPUs, but directly translates to battery drain on laptops.
It cost nothing to not change the pixels when you didn't press a key, no matter whether you weren't pressing keys at 60Hz or you weren't pressing them at 144Hz.
Vast majority of titles use deferred rendering, and lighting is done off screen too. Usually the only thing done to the "screen buffer" is a final post-process pass or a copy.
This is called 'compositing' but its similar in name only. It's a fairly efficient process where each color pixel is produced by reading these buffer targets and producing a final color in a shader.
This is entirely different from what composited apps do, where they build up the app's background into a texture, and push that onto the screen, with potentially multiple screen's worth of windows living in memory. This would be equivalent in video game terms to rendering every character and object in the level as 'stickers' and then making the final image of these cutouts, which would consume tons of RAM uselessly, and would force us to render crazy amounts of detail that would never get shown.
Regardless, video games normally update the entire screen (or window) every frame, because the screen is so dynamic. This is unlike Microsoft Excel which has a mostly static screen. Building Excel as if it's a video game is going to waste resources.