Re: Nice while it lasted
> But you must remember the qualification I made regarding what I use devices for.
Namely
>> But in the (my!) embedded world, most things I want to do, as a hobbyist, are more easily done with an ESP32 ... web sockets and networked storage usually suffice, when a small TFT or SD card is not enough.
The important thing for you appears to be the web sockets/networking (which is not something that every embedded project needs, by a long chalk, or you would not need the ESP32 in particular; in fact, it sounds like WiFi is really your requirement, as *that* is really the defining characteristic on the ESP32 over any of the other microcontrollers available prior to it, which could be used with a wired LAN adapter ).
In which case,
> If the ESP32 had been available then (it didn't arrive for another two years) then I feel the Pi range would not have built the lead it had.
But the ESP8266 was providing WiFi in 2014 whilst the first WiFi R'Pi was in 2016 and plenty of ESP8266 projects did Good Stuff before its big brother, the ESP32, came out. Even today, when people are asking why such-and-such a gadget doesn't have the biggest/bestest/most expensive ESP32 in it, you see so many, many projects that could quite easily run on an ESP8266.
IOW for the "microcontroller with WiFi" brigade the ESP family had a two year lead on the R'Pi. And before that, if a microcontroller with LAN was all you needed, those also existed before the R'Pi.
If the R'Pi was really going to lose out to microcontrollers like the ESP32 it would have been struggling way harder from day 1, going up against all the very capable MCUs that predate the ESP32. But it didn't, because it wasn't. The R'Pi has capable GPIO and in that sense it is comparable to microcontroller boards, but it's USP was, from Day One, to provide access to the GPIO, and every other part of itself, in a far friendlier manner than any MCU dev board. In particular, via the use of Python (which is *why* it is called "Pi"!) (and with a GUI desktop).
And in that respect, the R'Pi had a 7-plus year lead on the MCUs: MicroPython only appeared in 2013 and took a while after that to become widespread (and even now, on MCUs that support MicroPython, or the CircuitPython fork, many still use the unfriendly compiled language approach, because MicroPython does eat up a fair amount of resources that could be put to better use on devices with orders of magnitude lass RAM than the most meagre R'Pi).
Really, the R'Pi and MCUs are not in conflict with each other. Yes, there are projects done with an R'Pi that you say could just as well be done with a cheaper MCU dev board (ESP32 or SAMD or even ATMega). But there are MCU projects that could be done with a 555 (to use the classic Hackaday retort).
Maybe, with the maturity of MicroPython, including PC-hosted editors/IDEs, and the easy availability of MCUs that are vastly larger than the original IBM PCs, and the supply difficulties getting hold of R'Pis, more people are giving MCUs a go when previously they would have just gone for the R'Pi. Good. Don't let the AI-induced scarcity stop the hacking. But that is only "eroding the Pi's lead" in one, albeit great fun, segment. There are still plenty of areas people use the R'Pi where even the beefy ESP32-S3 with 16MB flash and 8MB RAM can not follow. Even ones that aren't just wordprocessing (yawn).
(BTW for clarity, I own a fair few R'Pis but, in all honesty, don't do use them for any of my own stuff: everything on them was someone else's project and I just grabbed a copy (e.g. PiHole). OTOH I have loads and loads of MCU boards and gadgets, mainly RP2040/2350 or ESP32 variants, that I code on (and, yes, do run other people's stuff on: WLED FTW). Plain old MCUs just seem so much easier to work with than R'Pi for blinky lights. Or anything that is small battery-powered and needs good sleep states with interrupt wakeups. Or real time control.)