I actually live in a no-man's land of being a very C-like C++ programmer. I completely agree with Linus about the problems in C++. But I take C++ as a version of C, then use what parts of C++ I do like on top of it. I basically have C but I can pick and choose to use other things, too.
The promise of class hierarchies making development faster and easier with more code reuse came as a double-edged sword. Not only does every class you make create a lot of overhead to manage (in the underlying machine code) but the common practice of requiring and returning complex objects from methods can requires a Ph.D in any library you want to use. And although the STL has safeguards greatly eliminating buffer overflows (common in C), it's very inflexible. Unless you are doing very simple coding, it can be more complex than recursive layers of pointers.
I spent a lot of time learning C++ only to learn that for every good idea, there were 10 bad ones. Theory ignores a lot of reality.
I do, however, think that C++ libraries can be well designed. This usually involves using a lot fewer C++ features but it isn't all bad. References, for example. Classes and instantiation, used minimally with only a basic set of data types passed in and out of methods can be very efficient at performance, memory footprint, and ease of learning/understanding/debugging. Sadly, this ideal is rarely the case.
Even making good use of C++ (which is rare), I think C is better for kernels and C++ better for desktop systems. With kernels, you are working damn close to bare metal and with desktop systems, you are working on a higher level and need to work with much larger scale philosophies in design.