Also the key problem is not iterated development but remote access (AKA backdoors) baked into designs as a way to hedge bets.
There's some cases where remote field maintenance is absolutely the right thing to do.
You would not send a space probe to Mars without the ability to radically change its software while in service.
When facing unknown future conditions the concept of deferred functionality is essential.
In situations of consumer electronics, which are designed, purchased and deployed within a rigid set of operational expectations, deferred functionality is a MASSIVE security risk and a subversion of expected trust models.
Convergence means that these days I can literally turn any of your devices into anything else... your wall clock into a radio, your fridge into a web-server, your television into spy camera.
It's not Agile as a development philosophy that is somehow "to blame" but its corruption by the devious into an excuse for reserving the ability to change functionality while hiding behind the plausible deniability of "necessary maintenance".
Not everything that uses electricity requires an embedded computer connected to the internet.
We could ask the question as: Give me a list of good reasons why a scooter should be connected to the internet?
We might get answers like:
Every one of these reasons, and many more, have nothing to do with the operation of the device qua scooter. Everything it did yesterday it could do equally well today.The problem is modularity, specifically the poor coupling and cohesion of subsystems within the design. Everything in our list relates to something other than the function as a scooter; like navigation, payments, telemetry.
In a properly designed system these have to be seen as essentially separate systems with diverged functional requirements. Each could operate and update in its own way if necessary. The default behaviour of the 'scooter' system should be to keep operating as a scooter, regardless.