I think his main point vis-a-vis C and C++ is that the kernel has a unified C culture and adding C++ would import a bunch of different C++ cultures. As a C++ developer in a C++ shop, I can appreciate this. Our shop has a very solid and consistent C++ culture. We can read each others' code because we all use the same language features and coding style. You can't do coherent C++ development without having this unity. The only way to develop a unified C++ culture for the Linux kernel would be for it to be grown slowly over time, starting from a small group of developers, the same way the kernel was. That can't and won't happen. If C++ is allowed into the kernel, a bunch of extremely skilled C++ programmers from different C++ cultures will start to contribute kernel patches written in C++, and it will be a tower of Babel.

However, I don't buy his argument that C++ is unsuitable because it's linguistically a high-context language. Part of this problem of context is solved by having disciplined, humble coders who know the limits of human intelligence. (I do not think these are new requirements that would exclude existing kernel contributors. C has, and the kernel uses, macros.) Part of the problem is solved by having a unified culture. The rest of the problem of "context" in C++ is really what would be called "state" in C, and of course you can't read state in the text of a C program. If you could magically create a unified and disciplined culture of C++ usage in the kernel, it would be fine. But that can't happen, so C++ is out of the question.