Earlier quoted context omitted.
7. insecure, opaque devices that have always-on internet connections, that owners cannot upgrade/fix/defend against and require external actors to protect (ISP's blackholing bad traffic) Remember, the S in IoT is for Security. They could simplify their business logic by making sure local first is reliable, and internet access can be turned off, and supporting vendors making (user-controlled, upgradeable, etc) gateway…
I don't disagree with you, since the company I work for supports both local network access to their devices as well as cloud access for when you are outside the home. But supporting both does not simplify business logic, it increases complexity. It introduces more states and failure points that your firmware devs and app devs need to account for.
The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection.
This would be the same mechanism a local-first connection would use, right? What am I missing here?