Pretty much everyone in the video games industry is going to disagree with this. Performance is the primary concern there, period. Languages that reject such ideas in favor of others simply will not be used, given a choice. Consoles also only run signed code, enforce NX, and mprotect doesn't exist, so there is very little in what can be exploited.
> Languages that reject such ideas in favor of others simply will not be used, given a choice.
That is the key issue, "given a choice".
I saw game developers being dragged into accepting C was replacing their beautiful Assembly, followed by game developers being dragged into accepting C++ was replacing their beautiful C.
You can be pretty sure if tomorrow Sony, Apple, Nintendo, Google or Microsoft said "you must use language X", they would do it.
So yeah, given the choice they can continue to lose money thanks to memory corruption exploits.
Signed code and NX don't protect against memory corruption. One can use ROP to work around it.
Again, bounds checking really doesn't show up in profiles. Iterators have none, and LLVM removes most of the ones that remain. It's really a non-issue.
> automate bots...
This has nothing to do with memory safety.