Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance. Making a complicated mobile game in C2 is easy, however it wont work because it's too complicated. The more difficult an engine is to work with, usually the better the performance you can squeeze out of it but the slower your development will be, ESPECIALLY if you are inexperienced.
You could very easily code a fast HTML5 game for mobile, however you wont have the wonderful abilities like picking which construct allows you to use, you'd have to build the game in an optimized manner. If your game is GPU bottlenecked, then that's going to be a problem no matter what. There's a lot of inexperienced developers using C2 (which is understandable) and they end up complaining that their game is working poorly because it works on desktop "just fine" but dies on a mobile platform. The only answer that can be given is that their game is trying to do too much, regardless of if it's doing "a lot less" than other games they've seen on the platform.
As an example, anyone familiar with demoscenes will understand that some people can squeeze a ton out of very little. Take for example classic c64 games and their graphics, and compare them to some of the more impressive demos for c64:
To top things off, most people abuse the hell out of collision detection in construct since they have a poor understanding of the costs associated with it and the mechanisms behind it's operation. It's very easy to blindly apply collision detection throughout code for repeated conditions, but really most engines have a SINGLE collision detection run per frame because it's so expensive, when in construct you can end up with many many many collision detections per frame, which make things "tighter" at tremendous cost. Behaviors are also a big issue because of how general they are, the expense they incur quickly adds up.
If you want great performance, you need a powerful platform, or you need to fine tune your game from the ground up, there's no magic bullet and complaints are misdirected for the most part.
Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal. In any case UE4 and Q3D have entirely different purposes, UE4 doesn't really work in browsers, regardless of what their poor HTML5 emscripten demos that barely work try to prove, they really aren't trying to make an engine for WebGL.