It was made for different use cases.

Nobody had a personal computing device in their pocket 90% of their awake time.

Now the goal for product department is to make their newly "smart" devices accessible to said computing devices.

The simplest solution that (almost) always works on home networks is to initiate an outgoing connection to an external server (the "cloud"), push notifications and poll for commands; after, have the mobile app only talk to the server.

If you do anything else, you are at the very least setting yourself up for support nightmare: "I am at home and I can't access my washer through the app" (are you on the same network? maybe your phone has wifi turned off?)

For usecases of the sort, this is one general solution that — from the perspective of a PM — always works.

By simply discounting reality that it's more expensive to implement both locally accessible smart devices, yet keep remote capability, and discounting that support costs are going to balloon too, we are not driving to a positive outcome for all of ourselves either.

I think we should focus on getting the cost down, by building better tooling and protocols and patterns that make it easy for a mobile app (or any client) to discover and talk to any smart device, making it simple for a customer to decide if they want remote capability or not.