I'll post here since I was referenced above by 
ErekT and feel everyone wondering about this should have a chance to hear it:
damainman and I both made Insanity's Blade, and the HTML5 prototype for Battle Princess Madelyn in Construct 2. We were both big time fans of Construct since Construct Classic where we both were working on various projects of our own (and we even met on the Scirra forums!).
If you went back in time, maybe even around when we were just Kickstarter funded for Insanity's Blade, and you had told either of us that we would be leaving the wonderful editor style of Construct (either Classic or 2) to program in C# (not even .NET but Mono C#) within the Unity game engine, I don't think we would have believed it (especially given that Unity was not free -with most features- for <$100k devs at that time like how it is today).
However, continuing on from a post that damainman made here: petition-to-include-built-in-exporter-compiler-in-constr_p1099702?#p1099702 , we have been building evidence that this is the right move for our company and our future games.
This breaks down into many reasons:
1. Native feels much smoother than HTML5 ever did, even on low-end hardware running the native version, VS mid-level hardware running the game in HTML5.
This could be explained away by someone else as "bad events", but realistically C# is so much easier to do wrong (eg: object pooling is a must!), so I don't buy that because we are literally getting better performance with the same two people making the code (although Unity does do things fairly differently to C2, sometimes better, sometimes worse since it's both a 2D and 3D engine).
It could be down to the engine differences instead though, which is where in Construct 2 the platforming behavior and collision systems always seemed to feel off when compared to Construct Classic let alone Unity.
Our take-away learning from this experience is don't use the built-in platformer behavior or trust the collision system in demanding games (eg: almost all enemies were platformer behaviors in Insanity's Blade for example).
2. We want real console support. WiiU without WebGL is a gaming laptop without the GPU, and the Switch doesn't even have a browser at release, so who knows when that might happen.
3. Some of the most important things actually are easier with code. One thing that I felt Construct always needed after hearing Ashley think about it was the "behaviors made with events" part. Families often felt like a kludge and picking errors would drive us insane/create a great deal of event duplication.
4. Pretty lighting and shaders. The community around Unity is so large now that you can pretty much find the resources and guides to do anything you want. There's also a great asset store for when you can't exactly make what you're looking for or someone else has done it better/for less time cost than you doing it personally.
Here's a gif from the Unity version with rain, lights, fog/mist, and lots of particles in action in Battle Princess Madelyn: https://twitter.com/CausalBitGames/stat ... 5139837953
We haven't actually lost any performance here from using these either, it's sometimes even a net gain when compared to the performance losses of the bare-bones HTML5 prototype running on JavaScript through a modified version of Chrome / Node Webkit.
5. Simple native APK export. This doesn't apply to Battle Princess Madelyn, but I have to say it's amazing when I can export a Unity project to my phone and have things almost run at the same quality as on my laptop. I click "Build & Run" and it shows up on my phone ready to go. (Currently developing an Android VR game for my thesis project at University)
but this doesn't mean it's for everyone! Construct 2/3 is still incredibly quick to edit when doing things that it works well with, and HTML5 isn't too bad of a way to share your creations with friends.
It's also still great for prototyping, understanding and learning basic game logic in schools for young audiences, maybe developing some non-game HTML5 apps (partially, sometimes pure HTML5 code might work better here too), and throwing together quick-and-dirty mini games for fun. I think this all points to meaning that Construct 2/3 is great and intended for hobbies, not full commercial titles on the scale of other indie titles like Hotline Miami and Owl Boy.
Unity is notably not-so-quick to develop with, but it's a pretty fair trade-off for games that actually run nicely across most pieces of hardware we've tested (even a tiny GPD WIN runs the game well!).
I could imagine it's somewhat (or maybe even "quite a lot") harder if you don't already understand some forms of code/C# in general, but I noticed it was pretty quick to pick up and work with.
Will this work for anyone else? It depends. Unity has its own known bugs and new bugs each build. Normally nothing too bad but still possible to run into from time to time if you try to stay up to date. It *also* has a team of hundreds of people though, so they are very rapid on the repairs! <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">
We wanted to make a serious indie studio with our games, and we knew we needed consoles to do that, so for us that's what matters most right now. I hope that sharing our experience helps! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">
As a personal aside: If Construct 3 had an exporter that dumped out a ready-to-run/export Unity (Godot? or some other engine with modern console support at least) project I would say "Great! Most people can now stay with Construct if they already know it and like it", but I don't know how feasible that would actually be <img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Surprised">
Then again, Clickteam has the Chowdren third-party exporter which looks pretty neat...