I've always taken that machine as a argument against event driven programming. Why? Well John Carmack articulated the problems very nicely when he wrote about inline code, covered on HN here:
The Therac problem was a result of states getting out of sync and into an undesirable configuration. I think reading about the machine and then the above Carmack will cause one to see the connection.
I see it more generally as the perils of unwarranted complexity. One of the bugs was a race condition that - I'm almost willing to bet - would not have existed if they didn't try to be "overly clever" and incorporate a crude approximation of a multitasking OS in their software.
It is mentioned almost summarily in the report - "Designs should be kept simple" is a phrase in there - but I think that this excessive complexity was one of the biggest factors.
This Hoare quote is relevant: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
> "incorporate a crude approximation of a multitasking OS in their software"
Many embedded systems have a 'crude' OS library... and in many cases this makes them far simpler than including an RTOS. Not having seen the code here, I can't comment on this one, but just including a simple scheduler is not necessarily a bad design decision.
The the other aspects of your "Keep It Simple" answer, I fully agree with.
https://news.ycombinator.com/item?id=8374345
The Therac problem was a result of states getting out of sync and into an undesirable configuration. I think reading about the machine and then the above Carmack will cause one to see the connection.