Idk I think it's not as easy to achieve a good front-end with point-and-click as you describe. When you have to do things like adaptive layouts, it seems like code actually manages a bit better than a WYSIWYG. Or there is some point of complexity where you need so many configuration options in a point-and-click editor that the code becomes easier to manage.
It's not that, it's that when you eventually reach the point where you need to do something that can't be handled by the WYSIWYG editor, you're left with 50,000 lines of shitty machine generated code that's almost impossible to work with.
The risk with WYSIWYG editors isn't that there's some tipping point where it becomes 10% more efficient to write code and you lose a bit of productivity or something. It's that something comes up half way through development and the WYSIWYG doesn't have the feature you need[1], and the entire project slams into a brick wall and dies instantly.
You can prevent this by running into the exact same problem CoPilot has, which is that reading code is harder than writing it. If you try to avoid the brick wall by having devs familiarise themselves with the code as the WYSIWYG generates it, those devs would have just been able to build it themselves in less time and with cleaner code.
[1] which will always happen eventually, because they're balancing the feature set for the exact reasons you mentioned. If they can do everything code can then the UX is going to be so bloated and horrible that it'd be trivially worse to use than just writing code.
