If all it takes is one human screw up with 3 lines of code to get full remote execution, you will inevitably get security bugs with that code. A best practices guide will not work, because people will not execute on their best practices %100 of the time. A language specification or at least a linter will enforce it %100 of the time in a practical comparison. This is why people want to sunset C family languages.
I do mostly embedded programming, which is overwhelmingly dominated by C. The reason I think C will probably never be replaced as the dominant low level language is inertia. Every microprocessor manufacturer knows they have to provide drivers, libraries, and board support packages for their parts. If they don't, no one will use those processors, because of the extra effort involved, and the fact that other companies do provide them. All of these drivers, libraries, and board support packages are written in C. Writing them in something other than C is basically equivalent to not writing them at all, because instead of forcing developers to reinvent the wheel, you're forcing them to use a language most of them don't know. In the end, it's the exact same problem: a large amount of effort required to get to the point where you can start implementing your application.
This same logic applies to real time operating system vendors. Everything is written in C. The minute they start writing their code in a different language is the minute their competitors become that much more attractive. On top of that, one of the major selling points of the major RTOSes is that they have mature code bases with decades of bug fixes and products using them.
Perhaps this presents an opportunity for disruption, but it seems like a steep hill to climb.
