Refeuh I can assure you that after multiple delays to do re-designs, re-codes and profiling of each of the mechanics in our game, we did not find much else that could boost the performance.
Work-arounds are something that we have specialized in since Construct Classic, so although your points are true that sometimes it is the games fault, it is also true that sometimes it's a fault in the engine.
As for changing the scope of the game to something smaller, I would, if our game wasn't something that basically could have been on 1980's arcade machines (https://en.wikipedia.org/wiki/Black_Tiger_%28video_game%29). The Next Penelope is an awesome game, but it could also be described as a top-down FZERO, which the SNES could handle if it wasn't in HD (Black Tiger ran a 4MHz Z80 CPU, while SNES had a 3.58MHz Ricoh 5A22 CPU, I know that direct CPU comparison doesn't count, but it's not entirely a "high expectation" that my game should run as well as these systems).
Ultimately the arguments of "think/dream/try smaller" and "are you sure/double sure/triple sure that you coded it right?" are not actually good methods of shutting down this conversation. Maybe native isn't the solution to the real concern which is poor performance on desktops and consoles, which we can see is not happening in Construct Classic, Unity, Godot, and many other tools that export to native/rely on existing OpenGL and DirectX runtimes.
As 
mahdi71 jokes, I actually would buy a Construct-style interface for 2D game dev that runs on the Unity runtime, even though I know how to program (in C#, Java, etc). I like the speed that C2 has editor-side for putting things together. That is why I'm moving on with future retail titles to use Unity instead of Construct, but still care so much about the future of Construct.
> Using HTML5 wrappers bloats the size of the project
>
It does - but no more than, say, deploying a software made in Java (requires JRE), C# (requires .NET), Flash (requires Adobe player), Unity web (requires Unity webplayer), etc. Even pure C++ has some dependencies (requires CRT libs, typically the msvcrt.dll variants people get when installing games on Windows). People install all these without complaining.
I don't see this as a very significant point when choosing a technology.
The real issue is that these wrappers don't just add a bit of bloat, but they are middleware unlike the Unity Web Player (which Unity can control), Flash (which Adobe can control), Java (which Oracle can control), and .NET/DirectX (which Microsoft can control).
Instead we're using NW which is based on Chromium, so it's Scirra having no control over NW.js, and who themselves have very little to no control over Chromium. So we're stuck when it comes to a Scirra-specific fix to hope that NW pays attention, and if they can't fix that (jank) that Google pays attention.
For example one shouldn't create a game and THEN decide to target the WiiU and the iPad2. These have so strong (and conflicting !) requirements they need to be factored in from the beginning (especially regarding art assets and use of alpha blending). Using native solutions doesn't remove this constraint. Just an example.
True, but Construct 2 should live up to its advertisements or have some small print like "WiiU as long as you don't use WebGL, complex coding, or expect real-time gameplay". Native does fix the issue of needing GPU support over Canvas2D as well.