Basically, I came to realize that a lot of programmers out there do not get the concept of "pay only for what you use". Which, inherently, make them "bad" programmers. I say "bad" as in "they can't write code that is efficient". These programmers might come up with very nice (as in, pretty) pieces of software. They also might come up with very stable piece of software. But they can't come up with code that is at least as efficient than code written by the programmers who know exactly the advantages of C over C++.

The main issue at hand is "quality of life". I now understand that there is a lot of programmers out there who are only "consumers". They consume compilers and languages (and, as an extend, processors) as they see fit for their convenience and not as they see fit for the efficiency of the final software. They only want to "get the job done", and do it in the most efficient manner for the number of lines they have to write, or the easiness of the code they write.

But a "real" programmer will actually be aware of the generated code. They do not care about their quality of life, as long as the generated software is slim and efficient. These programmers will know exactly what kind of assembly code is going to be generated as they write the source code. They are perfectly aware of each and individual cost of their line of code in terms of generated code size and speed. And C is the only language that fully provides this ability. Linus original argument can be translated into "if you are a C++ advocate for the sole reason it's easier to use for some programmers, then I don't want you to contribute to git, because you're most likely to be not aware of code efficiency, and thus, you're most likely to contribute non-efficient code into a project where efficiency is the main selling point."

Now, in an environment where the code is fully controlled, and where code contributors are fully respected and trusted, then C++ might be acceptable, because then one can trust them to do the right choices, and dodge the various pitfalls that C++ will present them. But in the case of open-source softwares, such as the Linux kernel, or git, where you can't possibly fully review every and each contribution being made, because there's so many, then C presents the advantage of fencing yourself against common bad programming practices that Object-Oriented programmers tend to be plagued with.

If you're a "good" programmer (as in, you know exactly what is the efficiency cost you're paying with the code you're currently writing) who still is a C++-advocate, then you're just ignoring the fact that there is bad programmers out there (as in, programmers who don't know or care about the efficiency of their code). Whilst I'm not saying it's absolutely impossible to do code in C++ that is as efficient as C code, I'm saying it's way easier to do insanely horribly non-efficient code in C++ than in C, because of the various pitfalls it presents to programmers. So if you're a "good" C programmer, you're probably a "good" C++ programmer too (as in the code you'll write in C++ will be as efficient as the code you'll write in C) . But if you're a "good" C++ programmer to start with (as in, you know how to do pretty things in C++, and write some insanely convoluted Object-Oriented C++ code), then it's not guaranteed you'll be able to write efficient code.

Of course, the notion of "good" and "bad" programmer diverges depending on the actual goal that's being desired for the job. But then C++ is still a horrible language on a lot of fronts: it's a bad Object-Oriented language - there's plenty of other languages out there who are doing a much, much better job than C++ to create Object-Oriented idioms - and it's a language that introduces so many pitfalls on top of C that the average programmer will write C++ code that is much, much less efficient.

In conclusion, if you don't like C, and prefer more modern languages, then I'm not saying you're a "bad" programmer as it's very probably you'll write code that is pretty, and runs nifty GUIs and even may be useful. However, I'm saying that if you don't see the advantages of C over other languages, then it means you don't clearly understand the philosophy behind C, and what it actually means to write code that's going to be as efficient as possible. Start learning about compilers. Learn about assembly. Learn about processors, cache lines, and other branch-predictions thingies. Then you'll understand why C is superior.