Are you sure that there are not other approaches that could make an integrated 3D engine work, or new APIs that would smooth integration? It seems to me that it ought to be possible to basically import existing Construct objects in to a 3D engine, so you can get the same result as using a 3D layer in Construct, but with that layer rendered in a 3D engine. Therefore the workflow would be the same as it is with addons now - using the Layout View to compose levels, perhaps using placeholders for 3D models and so on - but the runtime renders using a 3D engine instead of Construct's engine. It may be complicated, but I suspect it is possible to do something like that. If it is not possible, I'd be interested to identify why and what APIs could potentially be added to solve those problems.
3D engines are vast and complex pieces of software with a wide array of tools and features. I'm afraid I am skeptical that the requests for 3D features will ever be limited to just a last few. We've done a lot of 3D features now, often with people saying that's the last thing they need, but the requests keep coming. For example more recently, we did implement 3D direct rendering for effects. It was a pretty complicated change and resulted in a few difficult bugs along the way that needed to be figured out, including a regression that made its way to a stable release. But straight away, it turns out that's not enough and there are more features necessary. I'm afraid I am of the view that even if we did what you ask, people would go a little bit further, get stuck again, and then file a feature request saying "the last thing I need is XYZ..."; then if we did that, people would go a little bit further, get stuck again, file another request... and on and on, until we've reimplemented a full 3D engine. We've already gone a fair way down that path and I am getting increasingly reluctant to go further down it. This is why I am instead trying to explore alternative options: if you integrate a full 3D engine, you get all those features you'd ever have requested all out of the box. Then instead you work on ways to improve integration, rather than reinventing a full 3D engine in Construct itself.
Realistically, anyone wanting to do modern 3D with all the bells & whistles would be better served switching engines to something built to handle that task. This is a fine stance to have. But that full feature set isn't something everyone needs, and for many games built with C3 - indie games, with small teams - would not provide benefits outweighed by the events system, the one truly unique selling point C3 has. If users have to resort to entirely separate rendering pipelines and shoehorn them into C3, then C3 has lost all benefits and users may as well use those other more 3D-focused, javascript/web tech-based engines directly, because at that point, doing it in C3 is more of an impediment than a benefit, and WYSIWYG-style editors already exist for those other gamedev tools.
A majority of the efforts needed to have working - if a little retro, which is in and selling games these days - USEFUL 3D in C3 is already done. There are multiple examples above, including of projects that have already been commercially released, or will be shortly. Some of it required engine hacks to get working. The idea is that, moving forward, those hacks would no longer be necessary with SDK v2. That's the whole point of this discussion and has been since long before the announcement of a revised SDK to, ostensibly, deal with the current situation of engine hacks being required to do things developers need to do for their C3 projects that feature some amount of 3D content - even in mostly 2D projects with small 3D elements, or in project with more 3D visuals but still strictly 2D gameplay - the kind of thing (currently, with a few hacks) C3 already excels at.
What exists here, in this thread, is an "out" for Scirra. 3D can be done by those interested, capable, and dedicated to doing so, with comparatively little - much less than implementing full 3D yourselves - effort on Scirra's part. It has already happened. That door is not closing again. This is unlikely to change unless Scirra goes out of its way to actively - and maliciously - prevent end users from doing so. The remaining question is whether Scirra would like to make that easier or harder for some of its paying end users - power users - who will do it regardless.