We used to release anually in the data centre too. If the benefits of incremental and iterative deployment don't move you, consider all the iot security issues recently. And if that doesnt do it either, consider NASA's Mars rovers, Tesla, nest, and the multitude other embedded products that use updating to great effect. You may disagree, but gibberish is a bit harsh don't you think?
I don't agree. Today you can push out packages to embedded device easily; even tiny <4MB rom devices like openwrt.
You can push out regular updates, but you have to be very careful. You need to have full testing environments and real lab units of all generations to test on before you push to production and realize you now have a brick on the roof of an 80 story building that takes a week to get a roof permit form.
The cloud stuff is gibberish. Today's cloud is rebranded hosted platforms. I agree, I don't see the argument of making _embedded like the cloud_ being meaningful either. I know on my embedded projects we had a tight ship pipeline and you need that for the reason stated above. Sure you can do that with Docker/ResinOS, and it might help with building a piece of that, but I have a feeling it adds as much complexity as it might mitigate.
The embedded systems I work on are never internet connected and updated manually by trained service technicians when necessary.
Like the discussion at the top of this thread, we've really muddied up the waters when it comes to defining "embedded devices".
There are devices like mine, which are the early definition of the term (single purpose, low cost, tightly defined I/O) and then we have low cost highly compact computers, literally servers, that can be multi-purpose and are internet connected 100% of the time by design.
We don't deploy fast. We deploy once.