I think he's talking about operating system limitations. Elements in Mac OS are a fixed number of pixels. So increasing the resolution means making everything smaller. Lion seems to improve matters a bit by supporting 2x scaling, similar to iOS. But with this you would need an even greater pixel resolution (2880x1600px for the 15.4", 3840x2400px for the 17") to maintain the current scaling on the MBP.
LCD technology also doesn't scale all that easily. Smaller screens have greater yields, and so tend to be proportionally cheaper to manufacture.
You mean to say, Mac OS X Lion hasn't caught up with Windows Vista (or .NET 3.0 applications running on Windows XP) yet?
</flamebait>
I thought this feature was already advertised for OS X. It seems to me it was called "resolution independence".
Whatever name you give it, in Windows, application developers using the WPF API are expected to specify the size of their visual interfaces in inches (or the metric equivalents). OEMs are expected to specify their displays' resolutions in terms of number of pixels, aspect ratio, and diagonal dimension.
Then, Windows does the math in the background to automatically scale all visual interfaces on the fly from the abstract dimensions (eg. inches) to true renderings (ie pixels).
If the OEM fails to specify their screen's true resolution correctly, or if a user wants to override the OEM's setting to make everything appear larger (so it's easier to read) or smaller (to squeeze more information on the screen), they can use the Control Panel to do so.
Legacy applications, and generally all applications that weren't written to take advantage of the WPF API, are assumed to have been designed to target a "typical" screen resolution of 96 dpi. Therefore, Windows computes what the physical dimensions of the application would have been on a "virtual" 96 dpi screen. Then, it dynamically scales the application up or down to match the true screen's dpi, such that it takes up the same amount of physical space.