Kernel developers are often the kind of people, who feel happier, when it is immediately evident from the source, what the code actually does.
C++ has many more features, which hide what the code does more than plain C code hides it: overloads, virtual methods, templates, references, throws... C++ also has vastly more syntax you have to master in order to even understand the C++ code using it.
I think power of C++ is very powerful tools to create libraries and frameworks, which then make application development a snap. Very often C++ application developer would be totally lost in the template-filled innards of a library, even when he is very competent at creating applications using that library. And writing a C++ library right is a very challenging programming task, and only done in order to provide a great framework for the benefit of application developer. C++ libraries are not internally simple, they are (or can be...) just powerful yet simple from application programmers point of view.
But kernel API can not be a C++ API, it must be a language-agnostic API, so most of the nice things in C++ would not be directly usable at that interface. Furthermore, kernel is not really divided into "library" and "application" parts developed independently, with more effort logically going to one library, to make creation of a mass of applications easy.
Also, security and stability is more critical inside a kernel, and virtual methods are much more dynamic and therefore much harder to isolate and verify, than plain callbacks or other C-like mechanisms.
In short, while you could of course write any C program including a kernel as C++, most of the power of C++ is not well used in kernel. And many would argue, that programming tools should prevent you from doing things you should not do. C++ would not.