On the other hand, the issue is a tad more subtle. There seems to be an almost Pavlovian revilement and panic against C code, and this usually comes from people who haven't dealt with the language in a long time or at all in any depth.
For one thing, the blanket assertion that secure C code is a Herculean task, doesn't quite pan out. djb showed one way, based on a few general principles espoused in qmail, that has since successfully been reapplied by people like Wayne Marshall, Laurent Bercot, Bruce Guenter, Paul Jarc, JdeBP and so on. Much of it comes from abandoning the C standard library in favor of more robust alternatives like libdjb variants, clearly architecting process/module boundaries, using simple formats like netstrings and text0 that need not be "parsed" in the conventional sense, etc.
Further along the line, we have the SEI CERT C Coding Standard that comprehensively identifies many pitfalls. [1]
Deeper still, cryptography is one area where abstraction can be an enemy. You actually have to deeply worry about time complexity, branch prediction, precise timing, compiler optimizations and so on [2]. A tool like C becomes desirable here.
Lastly, but crucially - you're on Unix, for better or for worse. POSIX, SUS, all of those standards? They're deeply written with the conventions and API/ABI semantics of C in mind. Such is life. When you primarily write code at that level, the easiest way not to have any impedance mismatch is to just write it in C.
[1] https://www.securecoding.cert.org/confluence/display/c/SEI+C...
For crypto, at this point, C is now too abstracted from the hardware to be useful. You need assembler, and that's getting dangerously abstract too, since it's actually an abstract language over the microcode that actually execute, the entire point of which is generally to provide lovely, wonderful things... that trash timing guarantees that crypto would like.
"I had to write code that allows remote attackers to own the machine because it was the only way to avoid impedence mismatch."
Incidentally, since it hasn't come up, note that I consider "C + useful static analysis tools" to be a different language. "C + useful static analysis tools" can be a sensible choice. I still at least have questions about the cognitive load being loaded on to the developer vs. a language that removes the problems entirely, but it must be acknowledged as having radically different cost/benefit profiles. However, I observe that very few people seem to be using useful static analysis tools beyond -Wall.
I want to respect OpenBSD. To a great extent, I do. And there are reasons to prefer tested C codebases to untested code bases in new languages, sure. But to the extent I can't give my full, unadulterated respect to OpenBSD, it is because I don't see that they consider everything being in C a problem to be solved.
I mean, I get engineering considerations and that we can't rewrite everything at the drop of a hat and performance matters, etc. But it is my opinion that any engineer that cares about security really ought to see "written in C" as starting out with a huge entry on the debit side, and take appropriate actions. And every year that goes by that's more true.