Immediate mode is very common in game development. Super easy to reason about and debug.
It's used for quickly hacked debug tools to interleave UI and regular logic and not do a logic/view separation (as it would result in code bloat and a necessity for a refactor). You want UI code do some logic (like modifying properties of some game entity or renderer) and prefer to inline it. Lots of game code is effectively YOLO without even a single test. It's also typically guarded by IfDefs and compiled out of release versions.
But as soon as it stops being just hacky debuggers and people try to write proper tools in it, it becomes much more of a pain - people try to (poorly) emulate a retained mode in it, hold state, cache - and it becomes unreadable mess.
Effectively people are hasty and don't spend the time to try doing things nicely, in particular because the first steps and debug use allow you to do quick things.
But I don't think it's a fundamental property of IMGUI or Dear ImGui that "proper tools" become particularly more of a pain. Of course it is more work to make a proper tools than hasty-debug-tools, and I can easily see how underengineering can back-fire (over-engineering it likewise).
Web page: Wait for data from server, update page to match, this usually happens at most every few seconds. (or if it's server based) Fetch data, format into html, set to browser
Game: For 10s to 1000s of objects, run some code for each one at 60 frames a second. That code is usually one or more finite state machines and/or co-routines per object (or some hacked together code that effective does the same). This code updates a bunch of state for each object, and then other code displays the current state.
They're doing different things so they take different approaches.
PS: I get the above is over simplified.
ecs is just watered-down in-ram relational databases, and relational databases are also pretty popular for web apps
IMO there is also a few parallels between centralised event stores like Flux/Redux and ECS. Sure the data is organised completely differently (perhaps Flux can learn from ECS here) and updated differently (perhaps ECS can learn from Flux here) but the concept of centralising state is similar IMO.
This is either a nit or a completely fundamental difference that entirely changes the ask.
Immediate mode isn't _just_ about repeating the UI every frame
10 years after this, its still about the same... which is probably why an article like this has any controversy about it instead of being run-of-the-mill.
Retained mode is probably more common for user-facing GUIs, though.
I've been working in (mostly AAA) game engines and tools since the mid-2000s, largely in custom engines and i never encountered Dear Imgui, so i disagree with the "absolutely everyone". Pretty much every engine i've worked with (and didn't make myself) uses something like wxWidgets, Qt, MFC or some custom toolkit for the tools and custom stuff for in-game debugging (usually a console for keyboard use and some "page/screen" based reporting/lists/menus that are easy to navigate with a gamepad).
I do know that some game engines use it, but it isn't as universal as you think.
Qt, WPF, wxWidgets etc... was a good option up until 2015 or so, but since then the least painful way for writing integrated debugging UIs and standalone inhouse UI tools is Dear ImGui.
I'm showing my age here, but when game companies used to hire people to do tools, or leverage internal knowledge, it was often things like MFC in Windows... or the ones you mention. They would often run outside the game, often displaying lo-fi graphics.
The only "integrated" tool back in the day was a Quake-like console.
But eventually people started demanding tools that were more integrated, and immediate GUI was in the right place at the right time.