Anova could have, if they wanted, implemented MQTT to a local application on a phone using the exact same certificates and TLS encryption as the cloud.
The ‘local network’ is the common transport for both implementations and is consequently a ‘red-herring’ - a properly designed local application on a local network will always be more secure than a cloud-based version. Period. The local implementation would not have or need a permanent point of presence on the internet on port 8xxx as the oven does right now as I type (well, not in my case as I have blocked it on my firewall).
Critical infrastructure does not use cloud-based services for a very good reason and indeed go to extreme lengths to ensure their systems do not have any connections to the internet. And no, I’m not classing my oven as critical infrastructure
Bad actors go after IoT devices connected to the web by scanning known ports and looking for responses. When they get a response they then exploit know vulnerabilities in these devices. Vulnerabilities often do not surface for many months or years down the line but when they do it can be very problematic to get security updates and patches deployed when the product is no longer in support. Google Ripple20 IoT as an example. I deal with the fallout from this type of thing on a daily basis…
Bringing the discussion back to oven suggestions/improvements - The oven, as a minimum, should require the end-user to confirm remote start oven commands when the oven is not already running.