You forgot:

- The firmware running on the robot should have internet access

Seems like they're very focused on teleoperation or fleet operations as a use case so this makes sense.

Internet access is optional, or can be intermittent.

If you use the cloud service (consumption based & optional) then you'll need internet access for configuration, logging, etc... But if you lose connectivity, the robot will operate just fine until the TLS cert expires (always at least 30 days in the future). Configs are cached locally so even a full robot reboot without internet access will work fine.

We think teleoperation is important as making perfect fully autonomous robots is incredibly hard, and by having humans in the loop, we can achieve much more tangible progress on real world problems.

Honestly, as someone who has been building robots full time for 7 years, I am struggling to guess which use cases you are modeling your system design assumptions on and which alternative system architectures you believe you are delivering increased value against. Why don't you just describe them? It would be so much easier for people to grok what you're doing. (PS. 'Modern' is not something people care for in most industrial use cases. In fact, they generally prefer 'stable and well understood'. You may wish to reconsider your marketing strategy.)