When you press a button in an application to turn on a light two metres away, the command frequently travels to a data centre in another country and back.
That is not a technical necessity. It is a design choice with reasons, and it has consequences that most buyers do not consider until something breaks.
Why manufacturers build it that way
Several reasons, most of them legitimate.
Remote access. If you want to control something from outside the house, a server in the middle is the simplest way to connect two devices that are not on the same network.
Simplicity of setup. Local discovery and pairing is genuinely harder to make reliable across the variety of home networks that exist.
Updates and telemetry. A permanent connection allows firmware updates and gives the manufacturer visibility into how devices behave.
And a business model. A device that connects to a service can carry a subscription, and the ongoing relationship has commercial value that a one-time hardware sale does not.
What it costs the user
The dependencies that follow.
The internet connection becomes a requirement for controlling things inside your own house.
The manufacturer's service becomes a requirement, which means their outages are your outages and their business decisions are your risk.
Latency, which is small and perceptible. Local commands are close to instant; round trips through a server are not.
And privacy, since the pattern of your activity is being transmitted continuously.
What local control looks like
The alternative, which exists and requires more effort.
Devices that speak an open protocol, coordinated by a hub or controller on your own network, with the option of remote access through your own arrangement rather than the manufacturer's.
Several open protocols are established in this space, and there has been a genuine industry effort toward a common standard for interoperability, which has improved matters and has not eliminated the problem.
Open source home automation platforms exist and are mature. They run on modest hardware, support an enormous range of devices, and keep everything local by default.
The trade is setup effort, ongoing maintenance, and a level of technical comfort that not everybody has or wants.
The honest assessment of that trade
Having run both.
Local control is more reliable in daily use. Nothing depends on a connection, response is immediate, and outages do not affect the house.
It is less reliable in a different sense. You are now the person responsible when something breaks, and there is no support line.
Setup took me a weekend initially and the maintenance is perhaps an hour every few months.
Whether that is worth it depends entirely on how much you enjoy that kind of work. For somebody who does not, a cloud system that mostly works is a reasonable choice, and the discontinuation risk is the thing to be aware of.
The middle position
What I would actually recommend to most people.
Choose devices that function locally even when the cloud service is unavailable, which a growing number do. The key question to ask before buying is what happens if the manufacturer's servers are down, and reviews increasingly test exactly that.
Keep anything safety-related — locks, smoke detection, heating — off cloud dependency entirely.
Accept cloud dependency for things where failure is an inconvenience rather than a problem.
And avoid anything where basic function requires an account and a subscription, since that is the arrangement most likely to change under you.
The interoperability standard
Worth a note because it is genuinely relevant to buying decisions now.
The industry effort toward a common standard has produced devices that work across ecosystems and communicate locally, which addresses both the lock-in and the dependency problem in principle.
Adoption has been slower and messier than announced, implementations vary in completeness, and some manufacturers support the standard while reserving features for their own application.
It is a meaningful improvement on the situation five years ago and it is not yet the solved problem that the marketing implies. Checking what a specific device actually supports, rather than the logo on the box, remains necessary.
The question worth asking before any purchase
If this company stopped trading tomorrow, what would this device do.
If the answer is that it continues working, it is a reasonable purchase.
If the answer is that it becomes an inert object, you are renting it regardless of what you paid.
The privacy dimension
Worth separating from the reliability argument since they are frequently conflated.
A cloud-connected device reports state changes continuously, which over time produces a detailed record of occupancy, routines and behaviour within a home.
What is retained, for how long, and who it may be shared with is set out in a privacy policy that almost nobody reads and that can change.
There have been documented cases of such data being sought in legal proceedings, which is a use most purchasers had not contemplated.
Local control removes the question entirely rather than answering it, which is the strongest version of the argument.