Browsers are more easily available on every major, and most minor platforms than any GUI toolkit out there... Things like atom, brackets and similar make sense. They translate well between standalone app in an OS, or a platform app for the likes of ChromeOS, or as a SaaS app in a browser.
No, they aren't the fastest, lightest or best performing. They don't even have the smallest codebases... what they are is broadly available, with minimal variance and a lot of developers with most of the knowledge needed to maintain them.
I liked the way XHTML was going to remove the semantic and pave way for proper components, sadly it never happened that way.
Anyone experienced with XAML and similar layout engines can see how much better the browsers could be, if people wouldn't insist into binding a document model into an application engine.
Even with HTML 5, which still is a problem to support properly across multiple devices without a "debug everywhere" attitude, has less widgets support than a 90's GUI.
The situation is immensely worse on machines like the Raspberry Pi or the BeagleBoard. People have drunk the HTML5 kool-aid and now want to run HTML5 on such machines. When you see how these boards choke when running stuff like an asteroids clone in Firefox or Chrome, you weep. Write the same thing in C++, or in something like XAML/XUL/QML/Enlightenment Edje, and it is super smooth.
My favourite would be something like QML, but with Lua instead of Javascript (but a Lua variant where the array indices start with 0, not with 1). Lua is much easier to accelerate properly, as LuaJIT has shown.
The trouble is actually getting a cross-platform rendering engine working everywhere that HTML/HTTP already works... So, you go build it, get it working at LEAST on Windows, OSX, Linux, Android and iOS... then we'll see how adoption goes. More likely you'll see React* bindings take off with generators to whatever platform is targetted, with JS as the language in use.
