I've removed some offtopic chatter here.
Leitukey: Your desire for more stability has been noted. Please do not keep spamming it here, there is no need for that; I'd rather not have to keep cleaning up the thread. If you have other technical improvements you can think of, unrelated to what you've already said, feel free to post it here.
We will try to keep high integration and low cost in mind in our future chips. With respect to documentation and examples: we're working on this. In general, the software and documentation team is always actively working on improving the SDK, and while we do not have enough manpower to make the SDK the holy grail of all that is good instantly, we do strive for something that is well-documented and can be used easily. If you feel we're failing terribly hard in some specific facet of this, or if you feel some specific example is particularily egregious, feel free to file an issue in the Github
issue tracker.
Wrt multiple development modules: we already have a sort-of progression there: for development use, you can use a DevkitC; later when you make a device but don't want to be bothered by high-frequency PCB issues you can change to a Wroom32, and finally when your device is hot and you've ramped up production to many K-units, you can do the HF work and change to a 'raw' ESP32 chip to save a few extra pennies.
Wrt clock frequencies: I don't know the particulars of this, but it indeed is the WiFi and BT that have some very specific requirements wrt clocks. Wrt running the peripherals off lower clocks: from what I hear, this doesn't necessarily change power usage by *that* much, actually. For instance, we do nowadays switch off the clocks to peripherals we do not use entirely (we left all of them on in earlier esp-idf versions), and in a simple blink-type application, this nets us only 5mA or so of lower power usage. Now, I'm not saying that means running peripherals on lower clocks is something we'll never do, but I think it's more likely that we're going to allow people to switch any peripheral to 1 of 2 fixed frequencies (e.g. 80MHz or 1MHz) than give free reign to go wild in setting clock frequencies.
jimbob: I actually saw your post but forgot to mention I did. We actually are thinking about something like this indeed. Not sure if we'll make the ULP entirely superfluous, chances are it still more or less needs to run the show in deep sleep mode, but we have a few things in mind that make things easier. (About the ULP: I *can* tell you that programming the thing will get a lot easier because we're going to optionally have a different architecture ULP in the next version of the chip; an architecture that does have a full C compiler.)