> Anyone care to guess why someone would make this choice?

My guess: At some point in the past, a firmware was developed without plans to include firmware update functionality. The team that did this was later burned when the client tried to use a new certificate that the hardcoded, unchangeable system didn't recognize.

Angry meetings occurred, developers were chastised, and someone realized they could avoid that problem by fetching an updated root CA on demand. They did it over HTTP to avoid a chicken and egg problem.

In hardware manufacturing, everything is about crossing items off the list of problems. A problem was raised, someone came up with an idea to solve that problem, and it was implemented. The practice might have spread to other products because it became institutional knowledge about how to avoid a problem that made a customer angry once.

This is from my experience in the consumer hardware industry. If you're not watching the outsourced development closely, they will take the easiest route to solve the problem in front of them and nobody will consider any other consequences.

Hardware companies by and large don't get software. They just don't understand it. Their world is sourcing parts and assembly and packaging. They look at software like any other line item in the BOM: Like a screw or gasket. You source it from the cheapest supplier, and spoon it onto the product somewhere on the assembly line. These companies simply don't care about their software, and their requirements to their supplier amount to "make something work." The quality bar is literally "customer should not return the product."

Probably something like “What if the cert expires?”

Control and $