It's still a single core CPU, though, whereas the Xtensa-based ESP32 has a dual core CPU. Not sure people are actually using that second core in practice though.. And yes, this is probably an excellent case where RISC-V can win; wouldn't surprise me if RISC-V already has better toolchain support than Xtensa despite being a much younger ISA.
Some benchmarks on the earlier ESP32-C3 at https://hackaday.com/2021/02/08/hands-on-the-risc-v-esp32-c3... ; it seems it has the same core as the new ESP32-C5 except it's clocked at 160 MHz instead of 240 MHz. Extrapolating those ESP32-C3 benchmark results out to 240 MHz would suggest it's a bit spiffier than a single core Xtensa ESP32 but not enough to catch the dual core xtensa.
It's extremely common to use both cores on the dual core Xtensa because you can bind ESP tasks (WiFi/Bluetooth) to one core and schedule your application code on the second core, reducing jitter visible to the application code.
The cores were even named Core0 - PROtocol and Core1 - APPlication in the initial ESP-IDF design, where the core affinity model was going to be more strongly enforced (thankfully they backed off on this idea and now it is fully configurable SMP).
I make displays out of discrete lights and panels, when I use dual-core chips I usually use one core for driving pixels and scanning continuously while the other core does network stuff and actual framebuffer content updates. Makes for a very glitch-free and seamless experience :)
Once RVV implementations start working their way down into MCUs, there will be little to no reason for Xtensa, this probably a 3-5 year time frame. The ESP32 is going a bunch of SDR with Xtensa VLIW/DSP core afaik. You would have to measure cpu cycle jitter under adverse wifi conditions to see if the single core is an issue.
I would assume that the wifi stack is hardware scheduled on that core with dedicated scratch ram, and that the rest of the cache and cpu cycles are granted to the user visible core only while not needed. I think a whole lot of applications didn't use the second xtensa core on the earlier parts.
I think developers using the Arduino platform on the ESP32 are mostly just using one core. Developers using the Espressif's SDK are more likely to use both cores.
RISC-V is a way more supported architecture than Xtensa for the single fact it has upstream support from LLVM. After years Espressif still hasn't managed to get its LLVM backend upstreamed, which means using Rust or everything depending on LLVM is a hassle.
Speaking of which, Nordic bought out that WiFi startup late 2020 but have been silent on their WiFi mcu since
https://youtu.be/PLdpg-YXhv0