This isn't a forum for "non computer people" - I've been a professional embedded developer, hardware and software.
This stance is wrong and terrifying. The code, safety critical code especially, should be clear and should itself document the quirks of whatever it interacts with. Embedded has a culture of punting on abstractions due to the pervasiveness of cross cutting and global concerns (peripheral allocation, interrupt usage, tight latencies, etc), coupled with traditionally smaller code sizes. But we're no longer talking about devices with little memory or cycle by cycle timing, but 32-bit devices with dynamic allocation performing high level logical processing. The embedded culture of fiddling with stateful hacks, verification primarily through system-level testing, and then zipping up the source tree for revision control needs to be burnt at the stake. Leave the bit banging to single-purpose 8 bit micros at the edge that cannot hide actual complexity - the core is a full computer, and needs a proper type system.
I'm not saying this change is going to happen over night, but we should be aiming for the correct approach. Every time a company says that they cannot release code because it is too complex, wouldn't be understandable, have third party dependencies, etc - what they're really saying is that their code base is a sloppy hack, they have no idea how it works, and they really do not want to own up to this state of affairs.
> For me or any company to support someone's quest to understand the code would be a very costly endeavor that you're simply not entitled too or nor would it be a reasonable request.
It might not be desirable according to a company's business interests, but what is actually unreasonable is to force purchasers and users of heavy equipment to blindly trust the software controlling those devices.