It's that they're the only vendor supported method of working with the parts. If you build your product with an unsupported toolset and something doesn't work, you need to be prepared to reproduce the issue in the vendor support toolchain if you want support.
People coming from desktop and mobile development roll their eyes at this because they aren't coming across bugs in their x86-64 process or M1 Silicon that haven't already been patched over by some combination of microcode, the OS, and the toolchain. Everything works as expected.
Not so in the world of embedded. On modern complex systems, vendor involvement can be a critical part of the development process. Many of the products you have in your house like your router, Wifi gear, and IoT devices were probably co-developed to some degree with the hardware vendor. Starting with the vendor-provided reference design gets you to market much faster, even though you often could forge your own path with a separate toolchain and start from scratch.
It's still this way even in MCU development. You can go out and develop something like an STM32 system completely without STMicro's tools, but it's much easier to start the project in STMicro's tools and copy over the parts you need for setting up everything from clocks to peripherals, then to maintain a skeleton project in the official tools in case your separate toolchain starts acting funny.
