It's true that OS X uses OpenGL for GUI compositing, but that's only the lowest level. Above, there's a very important piece of the GUI stack called Core Animation which provides layer compositing.
Core Animation is used by both the native GUI as well as the browser DOM. When you use layer-backed compositing on a web page (e.g. CSS 3D transforms), WebKit implements it with a Core Animation layer. So DOM-based rendering enjoys the same benefits of GPU-accelerated compositing as native apps -- although obviously with rather different semantics since HTML+CSS doesn't map directly to Core Animation.
If you implement your own GUI framework on top of WebGL or Canvas, you're not getting Core Animation compositing for free, so you need to replicate that functionality in your custom framework. (This applies equally to native apps: a WebGL app is equivalent to a Cocoa app that renders everything into a single OpenGL view, and a HTML Canvas app is equivalent to using a single CoreGraphics view.)
I don't think the WebGL/Canvas route makes sense for most apps other than games and highly visual 3D apps. You'll just spend a huge amount of time building your own implementations of all high-level functionality that is already provided by the OS and/or the browser: layer compositing, text layout, view autosizing, and so on. If you're doing standard GUIs, why go to all that trouble?
> You'll just spend a huge amount of time building your own implementations of all high-level functionality that is already provided by the OS and/or the browser
Not only that, but you can't make a 100% guarantee that your implementation will look and work exactly the same as the native one on the underlying OS. For instance, I can re-create all the native Windows UI controls and re-implement all their behavior in exactly the same way, but what if the user has a custom theme installed? Everything breaks. (WPF has a similar problem.)
I agree that it would be a lot of effort to pull off since you'd have to duplicate a lot of the standard OS features in the browser but if eventually the DOM becomes an even bigger bottleneck, it might be a viable solution.
Core Animation is used by both the native GUI as well as the browser DOM. When you use layer-backed compositing on a web page (e.g. CSS 3D transforms), WebKit implements it with a Core Animation layer. So DOM-based rendering enjoys the same benefits of GPU-accelerated compositing as native apps -- although obviously with rather different semantics since HTML+CSS doesn't map directly to Core Animation.
If you implement your own GUI framework on top of WebGL or Canvas, you're not getting Core Animation compositing for free, so you need to replicate that functionality in your custom framework. (This applies equally to native apps: a WebGL app is equivalent to a Cocoa app that renders everything into a single OpenGL view, and a HTML Canvas app is equivalent to using a single CoreGraphics view.)
I don't think the WebGL/Canvas route makes sense for most apps other than games and highly visual 3D apps. You'll just spend a huge amount of time building your own implementations of all high-level functionality that is already provided by the OS and/or the browser: layer compositing, text layout, view autosizing, and so on. If you're doing standard GUIs, why go to all that trouble?