Good coding skills are very important, even in GM (it's not like MMF, you actually code/script stuff in it), no doubt about that.
But coding a feature like inventory is one thing, while having to code an entire engine from scratch is another. And then you have to test it (and it doesn't work), and then you have to port it to other platforms (and it doesn't work), and then you realize you need to add physics and particles systems with some editor (and they don't work). After several months, you realize that what you have is still not a game, but some basic engine that doesn't even have a fraction of features of Unity or GM.
I've been making games professionally for 7 or 8 years now and during that time had the chance to work on completely custom tools, GM-likes, and even those AAA engines. Custom engines are cool and very efficient, but even at a company where we had a fully developed proprietary framework (that took years to code and perfect mind you) and a programmer team to maintain it, we still had moments where we wished we simply went with Unity instead. When I went full-time indie, I consciously decided to go back to GM. For small indie teams, unless it somehow limits the scope of your game, I think such tools are the way to go.
I may complain about GM's faults and development schedule, but I can't deny the fact that I've had a completely playable demo of Cinders (which looked just like it looks now and had all the underlaying code work as intended) within a month.
I suppose. But it gets frustrating when there's a huge flaw that isn't your fault but the developer's of whatever tool you're using.
No doubt about it. But as Gabriel said -- it's a trade off.