>I mean, surely computing power is cheap enough these days that you can build all the intelligence you need into the device for day to day operation and simply use internet connectivity to get updates, such as security patches, and the like?
I work on embedded systems that can not fail when the internet connection fails, and it's bonkers just how much you can accomplish with a <$5 microcontroller or even a <$10 chip running linux. But the tide of the industry is pulling toward remotely hosting as much as possible.
Even if it doesn't strictly need networking, the desire for a companion app, firmware upgrade workflow and/or business desire for surveillance often justify it. Once you have network connectivity for any reason, well, then you're not not going to be phoning home to a surveillance system running in AWS anyway. If you have a companion app, making sure you can get a connection between the phone and device is going to have a fall-back path that runs through your servers because even self-styled techy people don't always understand networking.
Now that your networked device is already sending all the data home anyway, why not do more work serverside? Add in the prevalence of developers that can't be arsed to learn to develop for a microcontroller. Or those that can only get by in the very-handheld embedded environments. Now your design is starting to take shape, and you need to do some more number crunching. Do you invest in learning to leverage esoteric features of your microcontroller? Add a DSP to the BOM? Or just say it's easier to do on the serverside with comparatively infinite processing resources and the ability to rush development because features and bugfixes only require updating servers rather than pushing firmware to the fleet?