The GMS 2 extension system is a huge regression from GMS 1.x, and that's not to say the one in GMS 1.x is that much better.
For one, the biggest omission in GMS 2's extension system was dropping the ability to create local asset packages. They aren't just for selling to or sharing with the public, they are instrumental to private resource sharing and project merging workflows. Even for those containing only code, objects are sometimes needed to mediate in-game background actions, and sharing them properly requires the asset packaging workflow. Instead of porting the UI faithfully, some smart-alec at YoYo thought it's a good idea to force everyone to upload asset packages to the Marketplace and commit to a permanent ID, even those not intended for reuse outside the studio where they came from.
As is also the case with GMS 1.x, again there is NO documentation on anything at the native level but how to accept parameters and return simple values, and for only a few exports, how to trigger asynchronous events. Hooks to the drawing surface, audio stream, data structures, internal resources and other native-level resources remain largely undocumented, if they exist at all. Attempts to reverse-engineer these hooks come apart the instant something in the runner gets optimized. As a result, I don't think there is a single engine out there that struggles as much as GMS does with implementing video, audio and new forms of graphics rendering.
For GMS 2 specifically, YoYo designed the IDE ground-up to be extensible (so much so that EVERYTHING on the current IDE is actually a plugin), but to date the API docs are still on the cards. That defeats its purpose from the roots up and wastes the effort spent in its design. It also synthetically limits IDE work to only a small minority that knew the architecture's unwritten rules, thus the slow response to IDE problems for much of GMS 2's lifetime.
In my opinion, it would be hard to say that the extension system can be signed off in good conscience.