Once the norm for cross-compiling applications for MCUs, paid proprietary IDEs are starting to be outnumbered by free, open source solutions. However, the mere existence of free options doesn't immediately render paid options obsolete. The selling point of proprietary IDEs is that they provide the widest range of device support and require the least amount of attention from the developer.
Designed to work out of the box, the paid professional-grade solutions' claim to fame is saving developers time. These time savings will typically come in three main forms: unified environments for setting up an MCU, unified debugging environments, and vendor-supplied middleware, common across multiple MCU vendors.
Getting an MCU up and running is easier now than it ever has been, but once a project gets advanced enough that it starts defining specific memory regions in RAM and ROM or adding additional executable space in Quad-SPI-based flash, some additional configuration will be required. The best professional IDEs will provide some help (via GUIs), which makes these configurations a bit easier than needing to dive into scatter files and assembly-based start-up code (although these are excellent skills to have!)
Similar to the ability to quickly configure an MCU via a GUI, debugger support in pro-grade IDEs will also typically be very straightforward, generally limited to selecting the debugger from a drop-down list and possibly fine-tuning some settings.
If you read through all of the options that different MCUs could possess, it probably comes as no surprise that the same MCU won't be a great fit for every project you undertake. Being able to quickly move between MCU families (and even vendors) while maintaining a unified interface is an excellent advantage. However, getting locked into a platform-based approach, where hardware interfaces start to become defined (as well as firmware APIs), can be limiting, too (that is, Arduino or MBed hardware definitions).
Using well-written middleware from an established company breaks you free from the tendency of hardware-oriented platforms focusing on only the day-lighted peripherals. It moves the focus from accessing a particular platform's pins to accessing properly abstracted MCU peripherals. This distinction is subtle but quite important when it comes to design flexibility. Well-written middleware will provide consistent abstractions of MCU peripherals, as well as more sophisticated middleware.
The downside to paid tooling is the monetary cost, which needs to be evaluated against the development time, labor, and opportunity costs of a delayed product launch. Do you have an idea of the amount of time you can save by using middleware instead of reinventing that firmware wheel? What about the amount of time gained by having an IDE that works consistently for any processor you choose? Some basic return-on-investment (ROI) calculations comparing the cash outlay against honest and accurate estimates of the developer's time will typically tip the scales toward bought-in middleware for moderately complex projects. That is, of course, assuming cash is available to purchase software tooling.