For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day.
In both your examples, the real security failure wasn't in the IOT device at all, but something else (the Wi-Fi router, laptop, or user for misconfiguring security on those devices).
I'm no security expert, but out of curiosity I searched and found examples of low-end MCUs running RSA and AES-128. Probably not fast, but an IOT device is not going to be transferring megabytes per second. I agree that if you roll your own, it's likely to be flawed, but that's not so bad if it's a secondary security method - because then it requires successful exploit of two different flaws, rather than just one. (Whereas with a router and IOT device both running Linux, and going without updates for years as is common for embedded devices, the likelihood of discovery of a a single flaw that works for both increases; especially with complex security methods. I wonder how many embedded Linux devices are still susceptible to Heartbleed?)
But honestly, if someone has breached my Wi-Fi or laptop, a scary but harmless light show would be the least of my worries. In fact it would be a welcome notification. I say leave the lights unprotected, let them function as a honeypot.
A heater is a more serious matter. But starting a fire? No heater should be capable of setting the room on fire, simply by commanding it to, period. Sane thermostatic limits should be built-in, hardwired, and functioning independently of the MCU.