Firmware reliability for over temperature detection
Yes, they're 100% correct.

Safety-critical software/firmware and system design requires special considerations. You may find it worthwhile to sidestep the issue by using an approved mechanical over temperature limit as a safety, and the software limit becomes a kind of toy- if it works, it prevents the thermal fuse or whatever from failing, if doesn't nobody dies. That would probably be my recommendation if I was designing such a system. An analog sensor such as the LM335 could be fed in parallel to a comparator as well as your digital stuff, which would be way easier to certify, but as I said it might be easier to just insert an approved thermal cutoff in the power circuit and be done with it. 



It makes sense to certify software in high-volume products such as garage door controllers, gas burner purge and ignition control systems and so on where you cannot easily side-step the safety issues, or in low-volume high price systems such as industrial or transportation controls, but in a low-volume relatively inexpensive system it probably makes sense to minimize the NRE costs. 

UL1998 is one standard that I have some familiarity with, you may find this UL page useful- it has pointers to some of the IEC standards, of which one or another is probably applicable in your particular situation. 

Lots of things can go wrong with the execution of firmware- and there are ways to reduce the likelihood of disaster- programming unused memory with jumps to cold-start, checking all kinds of stuff before blindly kicking a Watchdog Timer (WDT) (most people know to use a WDT, but it's not usually used to best effect), refreshing internal locations and external ports regularly instead of assuming they always will remain unperturbed. That's just a few things.. there are more.