I disagree. Full control is the only way to enforce KISS. KISS is the only way to write secure software. Sure, a Garbage Collector, for example, sounds nice in theory, but in practice it is merely a tool that allows people that are too incompetent to do memory management to still use dynamic allocation. For example, with a GC you can never be sure freed memory is wiped before being re-used and that can change from one release to the next. Fully checked containers sound nice, but often it turns out they are not that fully checked, or have other limitations and bugs and quite often are not even fully documented. Talk about accidents waiting to happen. Only if you do them yourself can you be sure they indeed do what you think. And so on. I used to be a proponent of high-level languages for everything myself. Bit from what I have seen, they just make the problem worse when security is important.
Sure, if you do complex software, all these features help. But if you do complex software, it will be insecure. One thing that a language like C makes a lot easier is KISS, because as soon as you find you have to jump though hoops, you notice that you may be doing it wrong and too complex. Of course, if there were an alternative to C in low-level programming, that one would be just as viable. Since C is unique (unless you want to program assembler, that is), it has a special place. This may look like a "be-all hammer", but it is not and that is not the point.
Of course you should always strive to encapsulate the security-critical functionality and make it as small as possible (by KISS). Writing the rest in some modern language is perfectly fine and I am not arguing against that.
But the bottom line is that if the coder is not able to use full control competently, the coder is not qualified to write security-critical software. Mos coders are not qualified to write security-critical software, as we are seeing daily, no argument there.