The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. They had a lot of false starts: it took years before Wayland support actually got upstreamed in any regard.
Likewise for Electron. It does generally work to the point of daily-driver usability today with stable Chrome and Electron, but some apps are shipping old and out-of-support versions of Electron, so unfortunately it has become a bit of a waiting game.
Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run.
At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.
ChromeOS uses Wayland as a bridge between Android and Chrome because it's a politically neutral technology neither of them control, and thus can both agree on implementing. It's not about integrating better with other Wayland compositors or the wider Wayland/Linux ecosystem, it's about using Wayland as a piece of technology to sling buffers back and forth between two different camps who are otherwise on bad terms.
ChromeOS implements a Wayland compositor to support Android apps running as Wayland clients. Chrome being a well-behaved Wayland client is something completely different.
I'm not familiar with the situation, but my guess would be that ChromeOS has created its own Wayland compositor with a bunch of private protocol extensions that Chrome on ChromeOS uses to get stuff done. But for some reason or another, those protocol extensions are not suitable for submitting as new public extensions for other compositors to implement. Or they are suitable for submission, but the official extension roadmap already has different extensions in the works (but not yet complete) that will do the same thing.
Electron has different issues it's been working on, though. I believe it has some issues with window border rendering in some cases as well as issues with cursor size on fractional scale.
Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run.
At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.