I'm not sure I understand the arguments here. On the one hand, you have a set of technologies used for building web pages (HTML, CSS, JavaScript). These technologies can be used to write a native (as in platform-specific and first class) UI program using the WinRT API directly (something that is not possible inside a web browser - a context where targeting a specific underlying client platform doesn't really make sense...).

As I said earlier, when using JS in a Windows Store App, you have full access to WinRT and WinRT components (written in different languages). You can write a Windows application in HTML5. You can build an HTML5 UI that is powered by C++ underneath. You can leverage all of the WinRT API from JS. 

The reason you would do this (write a Windows Store app in HTML5) is to leverage your already-existing HTML5 skills to build Windows Store applications (which by definition means, again, you have the full WinRT API at your disposal). The fact that the underlying application execution environment is sandboxed doesn't mean it's the same thing as a web browser. It's not.

HTML5 is a set of programming tools used for building applications for the web, as we all know...

Windows 8 enables the use of HTML5 for building "native" client (WinRT) applications for the Windows Store, as we all know...

C