When talking about performance, I think it's important to keep in mind that the most effective optimisations are always performed at the high-level, i.e. game logic and resource management, that is turning "naive" things into "less naive" things, and either doing something differently in order to achieve the same result faster or compromising on the complexity to find a better balance between user experience and performance. Assuming the developer knows what the target platform perf killers are, as abusing alpha blending on a mobile chip that performs poorly in that area will never fly well ; just an example.
Only then, when all the low hanging fruits have been collected, can the low-level optimisations become useful. Platform specific low-level optimisations, such as vectorised math libs and so on, will unlock the next ~20% of performance, but it won't auto-magically turn a struggling 10fps game into a smooth 60fps one.
Also, these optimisations are exponentially costly, i.e. the more a software is optimised, the harder it is to optimise it further, and the more costly it becomes to save another 1ms. Plus, at this level, what is beneficial to one set of devices is usually detrimental to another, therefore multiplying by a factor ~5 all the work (desktop computer, console, high-end mobile, medium mobile, low-end mobile)
What I'm getting at here is the "game dev time vs performance optimisation time" balance ; when working towards a deadline reducing game development time is always the most effective solution, as it gives more time to perform high-level optimisations which will give the best results in terms of performance. That's where the productivity of tools like C2 shines. We can get something working quickly ! And then if performance is an issue in my game, maybe I just spend a few days to rework some behaviours or levels and save 20ms ; where it would take months of programmer time to save 1ms on physic collisions maths. That's a complete different order of magnitude.
Know your game, know your logic, know your devices. Don't rely on low-level engine optims and exporters for performance ; it can help, but there's no silver bullet.
Additionally, a quick word on broken exporters. It can happen. It's always a risk. Every company or project, big or small, faces the same risk, e.g. when choosing an engine, a tool, a service provider, a manufacturer, a 3rd party contractor, etc. They can defect, and you're never left in a good position. That's part of the risk assessment process, and ideally there should be a mitigation plan for it.
But most of all, choose an engine for what it is, not for what you want it to become.
Anyway, all of that being said, from my point of view the future of Construct should focus on the productivity of the game development tools : more user-friendly IDE, better debugger (huge potential time savings here!), etc. ; not on trying to cater for every details of every project on every platform.