IoM
The very first priority should be shifting the focus from the needs of marketers to the requirements of the meatsack trying to use these devices. The vast majority of this traffic doesn't need to ever leave the local segment.
In the case of those that do need to use the maelstrom of the Internet, there are certain design rules that should be followed. I wanted a vehicle tracker. I researched the various options from hideously expensive to cheap and shonky. All, without fail, required the use of some third party server, more often than not Google's maps crept in, leaked data like a sieve and kept quite a lot of numbers you probably didn't want them to keep.
I ended up designing my own. STM32+SIM800+Neo6, simple firmware that opens a GPRS connection and uploads a JSON string to my MQTT server over TLS every three minutes if the vehicle has moved more than twenty metres then turns the GSM radio completely off. Simple, effective, private and secure. I can then use HomeAssistant to grab an OSM tile and display the location on a nice map.
At no point does unencrypted data move out of my control. Nor is there any facility for communicating with the device over any public network - it talks, the server listens, then it says goodbye once a successful status message is received. It cannot be redirected, suborned, repurposed to carry out DDoS attacks or tricked into leaking data.
Other IoT stuff here include a weather station, solar charge controllers, various light and socket controllers and the garage door opener. All are custom built, all have ONE job and none of them will even acknowledge the existence of anything but the intended control channels.
The Unix philosophy works well in this arena and I commend it to my colleagues.