Death being a layer of aluminum away changes your mind.
I don't think the numbers you quoted are outliers, though. The F-100 lost ~900 out of 2,300. The F-106 lost ~120/342. That's a pretty big list of planes with a 1/5-1/3 loss rate.
There was a fuel tank mounted between the engine and cockpit so if it took enough of a hit to puncture right through (not hard, in practice) the failure mode was that the cockpit was now full of a 350mph jet of burning petrol.
Still, it did the job.
For complex reasons, available CPU time during landing was lower than expected (it was stolen by radar pointing peripheral). This caused regularly scheduled job to spawn before previous instance finished. As such, this caused two effects: job instances were suspended before finishing by new instances in the middle of the routine, and that pilling up of the old instances eventually exhausted resources and caused kernel to panic and reboot. Rebooting during landing sounds scary, but that actually was fine: such critical tasks were specifically designed to automatically restart from previously saved checkpoint data in the memory.
What was more dangerous, was the suspended tasks before restarts occured. First, it meant routine wasn't executing to the end, which in actual flight caused blanked displays (as updating the display was the last thing routine was doing). Any more CPU time stolen, and it could be interrupted even earlier, eg. before it sends the engine commands.
Another issue is that in case of fluctuating load, new instances could actually begin running to the end, and then previously suspended job instance could be resumed, potentially sending the stale data to the displays and engine.
And finally, while each job instance had it own core and VAC set properly managed by the kernel (think of it as modern kernel switching between task stacks), that particular routine wasn't designed to be reentrant. So it was using various global variables ("erasables") for its own purpose, that when interrupted in unluckly place might have caused very bad behavior.
How likely all of above is to occur, depends on the exact profile of fluctuating load caused by the confused radar peripheral. I guess that's why Mike Stewart is trying to replicate these issues with real CDU.