I guess the reason why this is the case is that code at that time was much lower level, and often had exclusive control of the CPU. I've toyed around with micro

I guess the reason why this is the case is that code at that time was much lower level, and often had exclusive control of the CPU. I've toyed around with microcontrollers before with Assembly and C, and I found it fairly easy to hold the entire mental model of what the system (registers & memory) is doing at each instruction. I feel this can lead to less bugs, as you can fully understand what each step is doing. Compare that to something like JavaScript running in Electron, where at basically every line there is a chance that something could return an error or take away control of the CPU messing up your time dependant code. Of course there are ways to handle that, but it's a lot more complicated compared to a CPU your code runs on exclusively. Or you just run into bugs with third party code that you need to work around, or update a library and find a patch version introduced a breaking change. This is probably why PLCs are so popular in industry. You can make sure a tiny part of the system works correctly and is bug free. Then as long as the contract of how it communicates & interacts with other parts of the system is defined properly, the system as a whole will operate correctly.