I think it’s a fair philosophical choice. Fractional scaling is really hard. macOS doesn’t bother, choosing instead to render at an integer scale factor and downsample. Doing something similar on Linux would be hard, for mostly historical reasons.
At first blush, it felt like a copout to have the compositor downsample. After all, wouldn’t that be blurry? Then it occurred to me: it’s always going to be blurry. You can’t draw a “1px border” at 150% without blurry edges. I am fully aware that rendering at a higher resolution then downsampling will produce a different result, but, still, so as long as we are piggybacking off the fact that our layouts are constrained to a pixel grid to make our UIs look nice and sharp, fractional scale will be blurry.
The story only keeps getting worse for fractional scale though. People who have used VSCode on fractional DPI have likely already witnessed a somewhat confounding problem: the terminal is not just blurry, but it is scaled such that it sometimes looks like it is 1px off height or width wise. Because it is. HTML is scalable and DPI independent in part because you are only ever exposed to the virtualized pixels. But on the flip side of that, this means that if you have a canvas somewhere, determining how many actual pixels you need for the buffer is not trivially possible. The grid fitting could be different at different corners of the canvas. This obviously is an example specific to HTML, but similar conundrums should naturally appear any time you have only DPI independent units exposed.
Using floating point can get you into trouble too. I have not personally experienced it but I have seen scaling artifacts in Qt that are apparently spurred on by floating point error. While I don’t know the exact mechanism by which this happens, it’s not too hard to construct a scenario in your head.
All of this adds up to a bleak picture in my opinion. Wayland has a very good implementation of DPI awareness that lets unaware clients fallback by simply doing nothing[1], which is a big step up from X11. In theory, Wayland compositors could try to avoid fractional scaling by picking an integer scale to advertise and downsampling all of the surfaces. But even failing that, at least you could push legacy apps to just see everything at 1x, and get the extra blurry visuals.
Until Wayland is a reasonable successor for all users, though, picking between pushing for Wayland for better fractional scaling over Xorg for better software or hardware support is a tough choice. It may not directly factor into Elementary OS and their decision to not support fractional scaling, but I can only imagine it’s not helping any. There are plenty of problems to solve and improve on in Linux that are a bit more tractable.
And then, after we’ve all finally solved all fractional DPI issues, the world will probably have virtually eliminated displays in consumer devices that look too big at 200% scaling. Of course.
[1]: https://wayland-book.com/surfaces-in-depth/hidpi.html
P.S.: I am fully aware I left out details here about font rendering, and some GNOME-powered Wayland issues like their horrid dbus API for cursor size change notifications. It’s already a long enough post that goes into the weeds too much.