When you say “this is explicitly for iot manufacturers…” are you referring to secure boot? That’s what I was referring to. I’ve done embedded development for about a decade, 6 at an IOT company, and our main motivation for using secure boot was to keep our firmware secure. The last thing we want is someone writing an article on the internet about how with this one easy trick you can break the security of the device and do whatever you want ( the devices are related to access control). If the company went out of business we’d have the option of publishing the signing key but it’d render all the devices vulnerable to malicious OTAs. Point is we’re not trying to lock folks out of tinkering, we’re trying to keep the devices secure. I understand as a side effect it means you can’t flash the device to whatever you want.
Also for what it’s worth these ESP chips are unbelievably cheap when bought at scale. The box the product comes in is probably more expensive
You obviously apply to the latter of my first paragraph. There are certainly applications where a device absolutely cannot be modified because then it defeats the purpose (i.e. security systems). What I'm talking about is something like a zigbee widget where it's job is non-critical. Not allowing user OTA updates is probably a good idea but preventing any changes to firmware for a non-critical device seems questionable.
Also for what it’s worth these ESP chips are unbelievably cheap when bought at scale. The box the product comes in is probably more expensive