Many limitations age poorly. I think TheAmpHour discussed Keil's (or was IAR?) 32K C/C++ compiler for ARM. "When are you ever going to write more than 32K of code?"
Like, every day? If a printf() takes 10kB of FLASH, bolt a SD card driver and some magic sauce, and you're over 32K. ESP32 Arduino executables start at 250KB IIRC, as it can include RTOS, WiFI, ethernet, audio, USB, etc.
I agree with Steve that in-house supported tools means more control over product life cycle is good. It is excellent to exactly know what tools and compilers you need from day 1. On ARM this is much more a mess or "DIY". But the reason why tools "must" cost money sounds more like an internal managerial side-effect that's exposed to the outside world. If the compilers were made free and a new manager is going to cut "costs" in a core aspect of product support, then that manager should be fired. Delivering "support" costs money, until it generates new sales in the future if you do it well.
Microchip seems to do very well despite their closed eco-system because its well documented and supported. But it also sounds like a risk judging by some of the answers. A hobbyist or small business could get a bigger/faster part if necessary. But if products need to excel in certain areas, then that is not always the solution. Optimization O3 is not only for higher Coremark scores, but also longer battery life (race to sleep). Optimization Os could mean more features and a longer product support cycle, which is also part of Microchip's focus on not obsoleting products. It's not always about the cheaper devices when boards get assembled.
Now the impact of these optimization levels is core part of the compiler marketing. I've found Microchip's compiler to be very slow, since so far as I can tell, it's compiling the program twice internally to give an accurate figure of how big the executable would be if you paid for optimization -Os. A compile with XC32 can take literally a minute for a project I did the other day, while it was completed within 5s using MIPS GCC. The newer MIPS GCC also delivered smaller and faster code. And supports the latest and greatest language features of e.g. C or C++ (like constexpr). This closed ecosystem also reflects a closed-mind approach on e.g. a lack of C++ for PIC24 devices (which are more than capable of utilizing it, see AVR/Arduino). Likewise, there is also no MPLAB X IDE or compiler builds for non-x86 machines, even though Apple seems to be selling tons of M1/M2 Macs and ARM PC's are emerging more and more. I firmly believe that if Microchip had a more open approach to their hardware tools and software toolchains, that their popularity amongst hobbyists would pick up greatly, which would then design in a chip into a product when they land their first job. Because [in general] on silicon level and documentation quality is at least as competitive as e.g. ST's.