The list above is not about distrusting the vendor or OS, it's about leveraging the vendor's officially published statements of behavior (e.g. HTTPS network traffic identified by PKI certificates tied to vendor's legal identity), used in contracts with enterprise customers that have competent lawyers, for the benefit of smaller customers.
MDM policy can be configured to narrow the vendor's documented claims of software+hardware behavior. Narrowed claims are cheaper to verify empirically. If evidence can be found that MDM policy is not being enforced, then the pool of affected parties grows from powerless individuals to a class action (Apple has paid millions in the past) and/or large enterprises who use MDM to protect confidential enterprise data.
> How do you ensure that the OS does not by itself connect to a random open WLAN
In the case of Wi-Fi, MDM and Apple Configurator can configure device policy to connect only to approved SSIDs + a null list of approved SSIDs. To validate enforcement of this WiFi policy, the device can be placed in a small faraday box (commercial < $1000, DIY < $100) that blocks external RF, with an SDR that records all internal RF traffic for analysis. For a device with a null list of approved SSIDs, there should be zero Wi-Fi traffic from the baseband radio.
Another option for MDM policy enforcement validation is to use a virtual iOS/macOS instance, where a hypervisor can perform live behavioral analysis of OS execution paths. Any unexpected behavior can be further investigated by reverse engineering of non-encrypted OS firmware binaries. Corellium offers a hosted service for virtualized iOS analysis, https://www.corellium.com. They won their legal conflict with Apple.
Finally, a third option is to modify the hardware device to disable unwanted radios, using only a wired network connection via USB. Past news articles have covered expensive modifications of commercial Apple hardware, for use by governments and companies in facilities where wireless networks were not allowed.
