Why, as an end user, would I ever care about this? All this says to me is that the part of the browser which should be fast and get out of the way is written in an abstraction layer with significant overhead (compared to the alternative, native code), which - to me - means using more RAM and CPU, increasing the cost or decreasing the performance of the device.
As a tech demo, I think it's a neat idea. But as a "one of the neatest aspects" of a commercial product, I'm not inclined to be interested in the rest of the app.
As for overhead the browser team has always concerned itself with keeping its footprint down both in memory and cpu and by using JS+HTML our total overhead was actually reduced compared to running another framework along side WebKit just for the Chrome. Checkout the above second video for more in depth presentation on this.
Disclaimer: I am part of the WebKit team at RIM these opinions are my own
Disclaimer: I am part of the WebKit team at RIM these opinions are my own
As mentioned in the video one of the neatest aspects of the browser is the fact that the chrome itself is written in HTML/JS. So the animations, transitions etc are all done by WebKit. The BlackBerry browser includes support for remote inspecting which meant not only could we host the chrome on our desktop while developing, but we could debug it from a WebKit browser on our desktop, all while it was running on the device. When you make a web application for BlackBerry10 it will be on top of the WebWorks platform which sits on top of the same HTML Runtime that the browser is using which aligned rim's interests to make sure that web applications work well.
For the curious a much more in depth look at the browser and how it was made was shown at this BlackBerryJam session: http://hosting.desire2learncapture.com/RIM/1/watch/50.aspx
Disclaimer: I am part of the WebKit team at RIM.