I keep thinking and reflecting on all this stuff (as you'd imagine from my walls-of-text).
It can also seem like Scirra are being closed-minded or something, but I think there's more to it.
Everything in this topic is not relevant to most projects.
It is mostly relevant to those who are making an ambitious project, or their project includes an ambitious system.
An ambitious system could be desiring 500 active enemies, each behaving independently with path finding and various variables to "think" about their behaviour. A new user will hit performance issues in so many ways where other experienced users would have an easier time achieving this.
But, if you're making a smaller game, or even a platformer with huge levels with many interactive objects, but no extreme systems, then usually this is achievable for new users, simply by doing the "intuitive" thing and throwing a layout together (and C3 works it magic with Collision Cels and such).
Is it the optimal way to go? Maybe, maybe not. Does it matter? That's Scirra's point that is totally fair for general games. If you have an ambitious game or wish to target weak devices, then both require the will to learn/measure.
If someone is new to Construct, Tech, or GameDev, then they will struggle to do ambitious ideas, until they learn and read and experiment.
Take "picking" - Experienced people know the ins/outs of this, whereas newcomers, even those that used a programming language before, find "picking" to be alien/unintuitive/confusing.
Whereas for me who has used Construct for nearly 2 decades, picking is the thing I have 0 issues with, even with the "quirks", which to me, no "quirk" in this area has prevented/stopped me/slowed me down from proceeding, we have many tools to manage picking - but when I was less experienced, you bet I was frustrated; looking back, it felt unfair to be frustrated, as the tools and documentation are provided for me to learn. It's easy for me to get stuck in my way of thinking.
Some of this feels true with 
nerdError 's post:
Even though I'm a big fan of C3, I really hate all the performance quirks it has. And you can mostly only find them by extensive testing and measurements (which with addition of all the random fluctuations and hardware dependency can be very time consuming and just lead to nothing). Well, also there is good amount of bugs too
It feels like this implies there's a lot of performance quirks, but I disagree here.
And "Extensive testing/measurements" - It's not like measurements take hours to achieve; New project, throw a sprite that "moves" (e.g. Sine behaviour) so FPS is not at 0, add your measurement tests (If needing to test many objects, a quick "For" loop to spawn many). Then test.
One would only test if they've thrown something into their project and noticed lag/FPS drops/CPU spikes. Or, if someone has a system that works fine but they yearn for more.
I do agree with the confusion being brought here with "how" to measure, but there's info here on some preferable methods. I also think that some measurements will give obvious results regardless of the CPU load and CPU speeds. Granular measurements are trickier, maybe the "I get X% CPU with 1000 objects, can I get a 5% CPU gain from another method with 1000 objects?" type of tests. But that kind of test is pointless; If you get your 5% CPU boost, then in-game when there's maybe commonly only 250 objects and rare moments of 1000, then the 250 object moments had gained maybe less than 1% CPU.
But in C3 you can ruin optimization of the game with so many random small things, and it explained nowhere. Docs are really bad in that. There is so much hidden things that are never explained, and they matter like A LOT, both for how your game works and how it performs.
With experience, it doesn't feel like "so many random small things". A lot of it is logical imo, and I'm sure most agree. E.G. Putting "For Each" as the top-level condition. Admittedly, I used to do this for my projects, but wasn't thinking logically; I just followed the rule of "Don't use them much", so I thought a single top-level "For Each" was ideal, but this was wrong. IIRC it is explained in the documentation for For Each.
But I do somewhat agree with a few random small things affecting performance for an ambitious project or system; the act of just using "Evaluate expression" within a "For Each" to gain some CPU is wild. But I say "somewhat agree" because it makes logical sense; "Sprite > Compare Variable" would do picking under the hood, despite 1 Sprite to pick, and it would be a tiny insignificant thing that C3 does, but could add up if designing an ambitious system with 500 enemies with subevents/conditions below the "For Each".
Also events have so much overhead just by default.
It's known this is true, but again, not for general projects, just ambitious things - The great thing about this topic is finding ways to get the performance out of event blocks.
Without that, it just a complete guess game and so many wasted hours
Well it's not a guessing game - Measure it! I also have wasted hours in the past, especially by trying to "measure" within the main project, rather than making a blank new project.
For example, just changing 9patch settings "Edges" and "Fill" to "Tile" leads to CRAZY performance cost. With 100 9patch objects, the amount of draw operations increased from 23 to... 1213, that's a 5173% increase just from changing a few settings on the objects that doesn't seem like they matter at all. Is it mentioned anywhere? Of course not
I think this fair to bring up but not an overall fair example. For one, 9 Patch setting changes are brand new from about a month ago - If there's performance issues, report it, and if it's by design or impossible to resolve, often a documentation tweak occurs.
And 2nd, Ashley highlighted, so won't repeat, but it's about thinking of the logic behind something - a 9-patch change is likely going to do something to the 9 pieces of texture it contains (except for the common Set Size and such).