I understand your position; however, the practice has shown, that this approach is good enough quality-wise. Most users didn't notice. In some aspects it is better than the approach you suggest would be, because it takes into account entire framebuffer at once. It will have less problems with pixel perfect lines, subpixel mouse cursor, etc, than the purely software solution, which will struggle with these more.
Also, it is not more resource demanding; the only cost is the bigger framebuffer. The scaling itself is free: it is done by the output encoder (that means output hardware that does the encoding for eDP/DP/HDMI; it doesn't use GPU at all for that[1]). Apple has one more trick: it doesn't offer the user zoom percentages as Windows or Linux Gnome do. You cannot do 125% on Apple hardware (that's bad corner case; you need to display 8 framebuffer pixels using 5 physical pixels AND you pay the price for @2X framebuffer). The default mentioned above (1440x900@2X) means displaying 9 pixels from framebuffer using 8 physical pixels. It doesn't compound the error at all.
We may discuss whether Windows did it correctly and Mac not, but the fact on the ground is, that all Mac apps run correctly on fractionally scaled displays and Windows apps are mixed bag. Even those apps that do support HiDPI on Windows have weird bugs (I'm not going to name & shame).
By which we are getting to another one of your points: that apps can scale their assets. Sure, they can. And as we can see, every app will do it incorrectly in it's own unique way. So when every app does that, why wouldn't system library do it for them? Any bugs you will fix in one place, and you might find a way to hardware accelerate it in a way, that the respective apps couldn't do (see above about the scaler on the output encoder).
As I wrote, this solution is good enough quality wise, is simple to implement and brings results quickly. Actually, it so so good enough, that Apple is using it in iPhones too (on some models, the physical and logical resolution do not match. The logical resolution is an integer multiple one).
[1] For Intel hardware, you can find more info in the Programmer's Reference Manual, Volume 12: Display Engine.
Also, it is not more resource demanding; the only cost is the bigger framebuffer. The scaling itself is free: it is done by the output encoder (that means output hardware that does the encoding for eDP/DP/HDMI; it doesn't use GPU at all for that[1]). Apple has one more trick: it doesn't offer the user zoom percentages as Windows or Linux Gnome do. You cannot do 125% on Apple hardware (that's bad corner case; you need to display 8 framebuffer pixels using 5 physical pixels AND you pay the price for @2X framebuffer). The default mentioned above (1440x900@2X) means displaying 9 pixels from framebuffer using 8 physical pixels. It doesn't compound the error at all.
We may discuss whether Windows did it correctly and Mac not, but the fact on the ground is, that all Mac apps run correctly on fractionally scaled displays and Windows apps are mixed bag. Even those apps that do support HiDPI on Windows have weird bugs (I'm not going to name & shame).
By which we are getting to another one of your points: that apps can scale their assets. Sure, they can. And as we can see, every app will do it incorrectly in it's own unique way. So when every app does that, why wouldn't system library do it for them? Any bugs you will fix in one place, and you might find a way to hardware accelerate it in a way, that the respective apps couldn't do (see above about the scaler on the output encoder).
As I wrote, this solution is good enough quality wise, is simple to implement and brings results quickly. Actually, it so so good enough, that Apple is using it in iPhones too (on some models, the physical and logical resolution do not match. The logical resolution is an integer multiple one).
[1] For Intel hardware, you can find more info in the Programmer's Reference Manual, Volume 12: Display Engine.