With quick-turn fab houses, you can do two-week sprints in hardware. You can fix up the circuit with X-acto/bluewire changes, and roll the fixes into the next sprint. Or you can make individual subsystems per sprint.
And with firmware, most software methodologies work with minor changes.
Usually you can get something working in the first sprint, and iterate from there.
For a simple project all of that can be managed iteratively.
Not everything has to be changed, that's just a strawman.
But not every detail has to be nailed down at the beginning either.
The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning.
But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.
It's impossible to foresee those all in advance—better to adopt a system that is structured to anticipate them. "Unknown unknowns" are a fact of life, no matter how disciplined we believe we are with our preparation.
"Ah, you have hardware version 2.3.1.3 - yes, it does sometimes emit sparks - we fixed that in the version that came out the month after."
Physical safety risks are an exceptional class of defects that in most jurisdictions has a legal requirement for the vendor to fix or replace the defective part(s) at their own cost (not to be borne by consumer).
Point: SPECTRE/MELTDOWN were not "physical safety risks". Yes you can argue they are security risks, but they didn't physically manifest as a physical safety risk which can lead to severe injury or loss of life.
Your commentary seemed to suggest you were not attaching an appropriate level of mental priority with regards to the severity and risk.