Me personally? I use PIC microcontrollers, and I use MPLABX and Microchip compilers to do my development for them - just as Microchip intended. Depending on who you ask, this combination is a steaming pile of junk.
It works because 8-bit PIC microcontrollers are relatively simple and projects are at most medium complexity, also Microchip has been pretty conservative in changing their software offerings compared to some others (people complain about any change, but people complain anyway; but writing C for PIC, compiling and flashing has basically stayed the same). Being low to medium complexity, PIC projects tend to have one developer. Also those who use PICs are also likely to use PICs for everything. Therefore just having a Windows machine and MPLAB installed on it to do the job works just fine.
Things get different with larger projects; teams working on them; external libraries; possibly many different microcontroller families involved. Now you suddenly need real software development practices, including versioning, tool standardization, using scripting instead of pointy-clickys, using actual code instead of code generation, ... And now, imagine that exactly
due to this complexity of projects, manufacturers think they can create business value by monetizing this need, and provide tools that manage all this, yet these tools do
exact opposite, drive the situation worse. When code generation needs to be get rid off, they add
more code generation. When pointy-clicking needs to be replaced with code, they create a library which makes writing code
even more difficult and
then add a pointy-clicky code generator to generate this impossible-to-write-by-hand code. This is what ST Cube et al really are.
It is an unsustainable equation: it still works
when the use case is as simple as PIC. When you still develop on a single computer. When you still don't use anything else than one microcontroller family (e.g. STM32). When reliability and maintainability doesn't really matter; getting
something quickly suffices. And when you are a young and eager hobbyist for whom transitioning into new paradigm every few years is fine. But as soon as you break out of these constraints, everything falls apart. This is why we see frequent threads describing the pain of installing, maintaining and updating three different IDEs and development frameworks, one of each going obsolete and transitioning into new framework every year, and creating instruction manuals with screenshots of what to click on pointy-clickys, and so on.
It is
much easier in the long run to just adopt normal software development practices: use classic tools; write code and scripts to do things, avoid pointy-clickys and code generation. Luckily, with ARM microcontrollers none of this shit is needed. (Compare this to 8-bit PIC, where Microchip's own compiler is the only option.)
This is also why I think the moment you go from PIC to ARM is exactly the right point of getting rid of the manufacturer tools. They maybe covered 99% of PIC use. Same isn't true for ARM anymore.