Writing an incompatible native exporter is just not very useful (see CocoonJS for an example of how annoying compatibility issues can be, and that's still got a fairly high level of compatibility). A smarter idea would be to rewrite the engine in asm.js, which can come very close to native C performance, and is still improving. But that would mean a complete rewrite of the engine, and possibly for no gain: GPU-bottlenecked games will see no improvement, and in many cases our carefully hand-written JS engine is fast enough anyway.
Ashley - I have to disagree on this point. I really think you're underestimating the value of a game engine without a complete browser feature list, and overestimating the value of those browser features. Looking at the tons and tons of games out there, an overwhelming majority of them could be made without a complete browser engine because they were made without a browser engine. HTML 5 tech for games is pretty new - so the games made without a full browser engine are the vast majority of all games ever made. That's clearly enough to make games with!
For example, I obviously can't speak for everybody, but none of the games I've designed and worked on have really needed anything that CC doesn't have (aside from exporting to other platforms and now multiplayer, which aren't exclusive to browser tech). Not one, and that's dozens of game ideas.
One of the main points is that you're making the choice for us, and you're choosing the option a lot of us wouldn't choose. If instead of writing the engine in asm.js and getting one platform, if you remade the engine in SDL or haxeNME or monkeycoder or some such, then you would only have to remake it once to get to a lot of platforms and - I admit I don't understand this process completely - but then couldn't you use emscripten to easily and automatically export to asm.js as well? I seem to recall reading it only took a week for them to get unreal engine 3 converted through it to asm.js. It would make the native exports AND the html5 export better! All for one code base rather than one for each of them (of course some tailoring would be necessary for each platform).
Doing that would be the best of all worlds - those who want more speed but not all of the features a browser supplies could have them, and those who want the extra browser features could use a faster web export through asm.js. Perhaps we could even continue using the third party plugins we've got if we want to export to HTML 5 (though I understand the third party js plugins would not have asm.js speed since they were not run through emscripten). It would give us the choice and option for either (and it's a choice a lot of us really, really want to have), would solve a lot of issues, make C2 look more like a serious development platform and would make a ton of us very, very happy!
As for the security issues, I think you underestimate them. It is a problem with native tech, and the problem simply does not exist on the web. I think there is a huge difference between downloading an unsigned EXE from a website you've never heard of before compared to downloading a digitally-signed installer for Steam from Valve. Some administered systems may forcibly prevent unknown executables from running. Some non-technical users may simply give up if they find out they have to "configure DirectX" (we know this happened in some cases with CC games), or get scared off by a security warning (which is there for a good reason). There are several hurdles here, none of which exist with HTML5 games.
There are tons of games out there which have the same hurdles, yet the PC remains a thriving place for games - in fact, indie games are thriving more than ever. A web browser by itself just isn't a proper platform for delivering a medium to large commercial game. People don't want to start up their web browser and go to a web page to play something they've purchased, by using an exe you can more solidly ensure compatibility since web browsers are in such a state of flux, and node webkit isn't totally immune to needing to update direct x either because it uses ANGLE and therefore direct x for rendering by default and comes with a dx installer because of it.
Regardless, if you did what I mentioned, it would again give us the option and choice. I respect your opinion on the matter but disagree, and I think we should have the options to make our own choices about which method of delivery to pursue. We could even do both and let the customer decide!
I really, really think you're underestimating the utility and value of the move. What's more, many of your current customers really want it, and I truly believe would lead more people to view C2 as a more serious dev tool and would translate to more sales. I would totally even be willing to pay for the upgrade, perhaps a perfect time to make it Construct 3. I hope you'll reconsider!