If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.
I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.
Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.
I shouldn't be running into bottlenecks on a 970. Or a 1070. Even the low-end target of a 750 (which should be lower, but can't be because of issues with C2) for Sombrero. If I'm running into fillrate issues in C2, that I don't run into elsewhere? That's a C2 issue. Period. Maybe the F2B renderer would have helped, but it was abandoned quickly and hasn't been brought up since. No point in waffling about on it - C2 is slower than the competition in getting things on screen. The reasons aren't especially relevant in the end.
So, no. No shifting goalposts. C2 simply isn't as fast as native, or whatever you want to call what other tools are doing. This is aside from issues with getting games running on as many of the platforms people buy games on as possible, which is also less of an issue with other engines, aside from the frankly embarrassing "support" for the Wii U, which was anything but, or the longstanding (years?) mentions of XBox One support that are still nowhere to be seen in terms of actually being able to RELEASE a game on the platform, with the features gamers expect. If I had to hazard a guess, we may end up relying on third-party support for that platform as well, much like Steam4C2 is much better than the support Scirra provides for Steam features, despite both being based on Greenworks.
I'm not talking about issues with HTML5, either; I'm talking about C2 specifically, and I suppose C3 considering it's basically just C2 with a different IDE, higher costs, more complex plugin development, and less flexibility for developers to do their own local builds with their own toolchains for NWjs on desktop & mobile.
You'd think that every dev that's made anything of scale in Construct having to move on to other game creation tools would be enough of a hint, but stand by your point as much as you'd like I suppose. The people buying games don't care about a game's tech, as long as it works as expected and provides good performance. It doesn't matter how easy C2 may be to use to make games if they have far higher hardware requirements, and are limited to less platforms than similar games based on different tech, limiting their market.
Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)
If memory serves, since I've long ago returned my WiiU devkit, this was due to Scirra's stubborn refusal to support the way the Nintendo Web Framework handled hardware acceleration, which was available for HTML5-based games. And didn't a third party actually have to finish implementing the framework, since what Scirra provided was the bare minimum of feature support, and not what NWF was capable of, even outside of hardware acceleration?