I'd summarise my stance like this:
1. I've shown with benchmarks that JS/WebGL performance can come very close to native. It may not do so in all cases, but I think it is closer than people think.
2. The rate of improvement is incredible. When we started in 2011 there was no option for desktop export, the latest IE didn't run HTML5 games at all, and Chrome and Firefox could just about stagger along at 30 FPS even on a high end machine due to software rendering, and mobile was so far out of the question that we didn't actually have any plans for it at all. It's getting so much better so quickly that I think a native export for any platform could be a waste of time since by the time we finish writing it, the web platform will have caught up.
3. We now list previous versions of NW.js at https://www.scirra.com/nwjs, so nobody will ever be stuck with a particular version if it has bugs any more. We'll stay up to date with NW.js updates and if an update is broken, you can roll back easily from that page. The "jank" issue is just a Chrome bug we inherited, and should be fixed in due course, and is not some fundamental shortcoming of HTML5 (as IE11 demonstrates with its very good v-syncing).
4. I think it is a good thing we do not have to maintain NW.js or Crosswalk. This would be a tremendous burden on us also. Chromium is over 20 million lines of code and can take around a whole day to fully build. Maintaining that over 7+ platforms (Windows 32/64, Mac 32/64, Linux 32/64, Android) is a great deal of work and probably best left to Intel's engineers. Also, this probably would not actually be a big help anyway, since the jank bug came from changes made to Chromium by Google engineers, and we aren't going to watch 20m lines of code for breaking changes which Google can't spot themselves. The best solution is just to make old versions available for rollback, which we now do.
5. Working on native exporters is a colossal project and we probably would not be able to write any other features at all on a timescale of years, or possibly ever again, if the work maintaining so many codebases proves to be time consuming. I am confident C2 today would have a fraction of the features it does if we had the added burden of maintaining multiple codebases. Further, it would end up with ongoing portability headaches forever, and some users from other tools complain bitterly how they can never predict which features are available, or will work correctly, on which platforms. That is something I specifically want to avoid, and I do not believe anyone who says "it will be fine if there's just a few features that work on native", it will be an ongoing cause of pain to users indefinitely.
Given my perspective, I find it difficult to see why writing loads of native exporters is a better idea than improving what we already have to a native-equivalent point, which is definitely possible.