Sure, though consider VB apps weren't
that sleek considering that typical RAM in the late 90s ranged from 32-128 MB commonly:
http://www.tomshardware.co.uk/forum/266641-28-average-1998-c...And of course in the early 00s the VB crowd largely moved to the, at first, much more resource-intensive (all-in) .NET..
Electron apps certainly seem quite wasteful and probably should be short-running one-off tools for now, rather than long-running major LoB or productivity apps.. config editors or media tweak things or such. Of course if it takes 500MB out of my 32GB RAM that's not cool (but kinda in range with ~1/64MB), but if I run it and close it after 10 mins it's also not the end of the world if it performed a job that needed doing.
What the embedded browser provides is of course both a GUI toolkit and a runtime framework, so just in-place-of a .NET or a JVM or some custom combo of (C++ std shared objects + Gtk/Qt/Etc libs). YES: this sort of "browser as runtime framework" isn't currently optimized for the Electron use case. But if efforts were invested in such optimizations, it would probably benefit browsers as well. And though it is unlikely, it is slightly likelier as the younguns adopt Electron for much/most of their hackery.
Consider: I think there's countless native app developers who sometimes yearn for the great design freedoms afforded by the infinitely mallable HTML+CSS. It is only for efficiency reasons that native still wins. That being the case, if Electron etc (embedded html/css renderer and runtime via JS) approaches were as fast-as-.net/jvm-bytecode, it would easily become the prime choice. So maybe it's just too early to discount entirely.