It only takes a single incident like Heartbleed, Shellshock, Backblaze or whatever to render a formerly assumed secured component or protocol insecure.

And if you're building something on a platform where you can't rely on the ability to upgrade past the latest SSL security vulnerability in the future, you effectively can't count on HTTPS to provide the security you need for the lifetime of the device. That means you'll have to implement additional means of securing your data anyway, so what value does HTTPS provide in those cases?

In some cases the library affected may now instead provide a security risk in itself, which you wouldn't have had you only gone with plain HTTP. So it can be argued that deploying HTTPS in environments where the ability to perform updates are limited is a security risk in itself and should be avoided at all cost.

So if you're going to have to implement your own security anyway, why bother with all the additional work, complexity and security-risks using HTTPS involves? Especially considering you probably won't gain anything out of it, except more work.

Counter to popular HN religion, HTTPS everywhere is actually not always going to represent a security benefit.

In lots of cases, plain HTTP just makes sense.

Edit: Not to mention the increase in complexity brought you by HTTPS effectively means you now need to provide more updates for your devices, or leave them vulnerable and hope nobody notices.

Basically, blindly applying HTTPS where it doesn't provide value, now just increased the cost for companies w.r.t. maintaining their devices in the future. If a company sees increased per-device-lifetime-costs associated with updates, guess how many companies will then decide on limiting the number of models they are willing to provide updates for, labelling older models "obsolete"?

All in all, HTTPS in cases like this represent a negative value proposition both for the companies and the customers.