[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...
[2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
So I think it's actually good to strip these out. There can be added as external modules or you can choose a board better suited for the job at hand.
However, it's not like this breaks security of your hobbyist projects.
OTOH, the RP2040 doesn't even have flash encryption or secure boot. Which I guess makes sense, given that it looks like a first mass produced MCU designed specifically for education/makers/hackers.
At that price point you should just be thankful for what you're getting.
The described exploit requires physical access to the device PCB and precisely timed fault injection, so it requires moderately sophisticated attacker have the device entirely in their control in relative privacy to even perform.
As I see it, the Secure Boot bypass is thus only really relevant to those concerned about a supply chain attacker replacing the firmware. I don't really know how large the overlap is in the venn diagram of those with legitimate concerns about such things and those buying ESP-powered products though as the ones I'm aware of are pretty much all consumer-tier IoT things.
The ability to decrypt encrypted firmware is of course a different matter, even if it doesn't contain any real "secret sauce" most companies don't want their code to be accessible to competitors and/or cloners. See ELM327 for an example of what can happen there. That said I still wouldn't call it a "grave" vulnerability from the perspective of anyone but corporate IP lawyers, and in general screw them.
From a hobbyist perspective these are both good things because they enable hackers to modify their own devices to improve them.
This is a good first version to validate if their customer base is interested in such a product from them, WiFi/Bluetooth can be on V2.