Those examples are interesting, specifically because history has shown us this point of view to be erroneous through those exact systems.
Automotive control units that are supposed to be segregates from certain data channels sometimes aren't. That was the cause of the Jeep remote hijacking stuff.[1] Any automation has to have some inpute and output to be useful for more than anything as a heater, and assuming your inputs aren't "networked" may not be valid given you likely can't control exactly how it will be used now or in the future.
For aviation, there have been problems with assumptions regarding the integrity of the channels used for communication between planes and the ground. This has led to certain systems being exploitable, even if not as bad as the initial hype made it sound.[2]
1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...
2: https://defcon.org/images/defcon-22/dc-22-presentations/Pols...
As long as no one does something silly a decade from now when it comes to the networking on the plane/ship/factory.
Safety is a property of a system and the context in which it's used. Safety is not a property of its individual components, including its code. If your CPU's GPIOs were directly accessible through the Internet, your computer would be hacked too; does that mean your system is not safe?
Your claim that MISRA and standards for safety critical software also provide security against targeted attacks does not really follow.
A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.