If you read enough security literature, eventually you'll come across the notion of a "trusted system". And your first impression will be that this is a system which is fully debugged and tested and you can trust it to do its job within specifications.
But you couldn't be more wrong. A trusted system is one which you have to trust. No representations are made about whether you should or not.
This is not relevant. If a corporation builds a product that kills people, the corporation is responsible. No corporation is responsible for the behaviour of humans.
No hundred humans are running the exact same OS that can deadlock or crash and as a result drive off the road, which is why this trope about humans being worse than computers at driving is entirely irrelevant to a thread about why it's unwise to try to build self-driving cars on top of Python scripts.
My take of the OP's point was that the deep general stack was unnecessary and decreased reliability. My read was that they think your self driving car software shouldn't also be able to run arbitrary python scripts. My argument is that it's practically irrelevant to reliability. I would not be surprised if in the future you could download an app to your iPhone, connect your phone to your car, and have the app drive your car. Sure, maybe having a specialized real time o.s. without any higher level interpreters could be more reliable in the early days, but the gains from rapid iteration you'd get from allowing cars to be driven by apps running on higher level abstractions would be worth the trade off, and over time the latter could be iterated upon to achieve practically the same reliability as over-engineered systems.
We entrust humans with operating cars right now. Humans in a sense are running a general purpose OS.