Maybe but are not. CAN silicon is especially an issue for me. Have acceptable IDF patches (thank you ESP) on my IDF revision but then ESP refactor between versions with huge changes & my patches no longer works & I do not have a clear/easy route forward.'The chip and firmware may be "fine"'
So the IDF offer is not stable IMHO.
And before anyone piles in; a CAN stack which allows corrupt frames and/or locks after the first overflow is not release ready.
Neither is a MQTT client which fails on WS socket frame/packet fragmentation.
In my world these are basics. Am I the only one who tests?
Upside is I have had some good & great support & that matters lots but downside is I just want to rock up, type code and deliver & not hang my arse out in top office during another IDF/silicon saga.
I think the IDF approach is somewhere between limited and flawed. I accept that IDF is so such that open source libraries may be used i.e. the IDF is threaded such that linux etc libraries may sit on top. Some of us however need faster SPI or I2C and that is not going to be easy with a threaded API. Try talking to an MPC2515 for example using IDF SPI. Device driver latency, GPIO mux & bus constraints will bite you.
Additionally ESP32 has some significant bus issues/limitations. I have not quite needed to address these (they nip me from time to time but I have so far avoided that rabbit hole). An ESP overview would be wise as these constraints can ruin a project. Silicon again.
If I were to score the offers; STM, ESP/NXP then maybe PIC but why would you PIC these days? STM owns imho.
That's a software perspective, you big volume guys n gals might have another view. I'm on 10K pa and that's my view.
EDIT: And the silicon work arounds/documentation gaps are such that you cannot easily produce a bare driver.