Very compelling, but the conclusions seem jumped to.
How can you be so sure "spaghetti code" means OOP? Others have said the Toyota brake program was written in C, which doesn't rule out OOP but doesn't prove it either.
Is it really such a bad thing if the executable looks like a mess of conditional and unconditional jumps? That discourages reverse engineering, which, for what it's worth, corporate executives probably consider a plus, as it theoretically protects the company's intellectual property (though of course legal still wants to put a clause about that in the EULA).
From what I've read on the Toyota brake problem, the reviewers were allowed to examine the program source (though under heavy guard and with a strict NDA).
Theoretically, the program source should reveal a structure that is not discernible from the executable's byte sequence. Apparently that was not the reviewers' experience with the Toyota program.
"Spaghetti code" is certainly difficult to test. But it's certainly possible for a functional programmer to skip testing, though for different reasons. And then, next thing you know, two functions that work as expected compose to something that doesn't work as expected.
Maybe that's the cause of the vast majority of problems: faulty assumptions about how a program works.