Now you made me doubt myself, because I'm pretty sure that analogy was the weakest part of what I wrote, it was just how it seemed to me when I was writing.
On further reflection I think maybe reputation for performance matters rather than performance itself. But I have strayed far off topic.
> On further reflection I think maybe reputation for performance matters rather than performance itself
I think that you're vastly overestimating the importance C as an abstract specification and as a community of programmers with a coherent set of shared goals. You're also too focussed on performance. There is a practical sense in which C will tend to perform better for certain tasks, but it doesn't necessarily have all that much to do with the language itself. It's the whole ecosystem. And yes, path dependence matters. It isn't intrinsically true that it has to be this way, a little like how it isn't intrinsically true that we have to use QWERTY keyboards instead of Dvorak keyboards.
It's not that there aren't lots of serious problems with C -- there certainly are. It's that those problems are systemic problems; they're more the result of a huge number of people making a huge number of pragmatic decisions, day after day, year after year -- and the sequence matters. Many of these people are not computer programmers. Many are from hardware vendors that have people that sit on standards bodies for everything from NVMe to RISC-V. These are all people that more or less all look at the world as it actually is today, and build on that incrementally. They build accretions on top of accretions.
There are many glaring contradictions in C. Depending on who you ask, it's either a portable assembler, or a programming language that targets something called the C abstract machine. And neither party seems to want to even address the glaring inconsistency! This is a cabal that seems to have a real problem with staying on message, don't you think?
I make only very modest claims here. I'm not saying that this is good or inevitable; only that it is the best explanation I am aware of. I'm definitely not saying that we can't do better. Only that I believe that the current state of affairs works as well as it does (i.e. barely adequately) because in the end it's very difficult to get an enormous number of people separated by time and space to agree on anything at all. C more or less remains the defacto standard when operating at the hardware/software interface not in spite of its glaring contradictions. It's because of them.
It's all but impossible for me to prove any of this, because I'm describing diffuse, emergent behavior -- what I'm arguing is that things tend to take the path of least resistance, in an environment where companies come and go, and short term business considerations hold sway. I might be willing to put more effort into convincing you of this if I really was the C zealot that you imagine me to be, but I'm not.
I'm not sure there are C zealots. There are definitely C++ zealots, but I don't see that level of burning passion for C.
As to the "inconsistency" between portable assembler and abstract machine, surely the problem is that the people who claim its a "portable assembler" aren't talking about a compiler they wrote, or a standard they authored but their (wrong) expectations for somebody else's compiler and standard. I don't see this language from WG14 (the committee) or the compiler vendors.
On further reflection I think maybe reputation for performance matters rather than performance itself. But I have strayed far off topic.