Your getting downvoted, but you are kind-of correct. Even if it isn't actually written in C++, there is a lot of "OO-style" code in the kernel that does things like dynamic disoatch using VTables...basically making explicit what C++ is going to do behind the scenes for you anyways.

I can see the argument from Linus' POV about avoiding over abstraction, and knowing exactly what your code is doing on a low-level, but at the same time it leads to a lot of reinventing the wheel and makes me think there is a better balance to be found.

https://lwn.net/Articles/444910/

https://lwn.net/Articles/446317/

It doesn't only make you think there is a better balance, it also makes you think harder whether the task at hand needs this kind of complexity. If this is all hidden under abstraction, developers might not care enough.

I absolutely agree with you on the dangers of overabstracting / hiding too much detail. That said, I do wonder if things have changed, since Linus's c++ "rant" re: the type of developers who would choose to work on kernel code in c++. I do remember a time when learning c++ was very much in popular, before the "in" language moved to java, to python, to JS, etc., so there may have been more of a problem with inexperienced coders back then than there is now. (I have no idea if this is true at all, just curious!)

I'm addressing this as someone who has done C++ work on very small embedded systems (e.g. microcontrollers with no external memory) including RTOS code and low-latency control loops, and there were definitely some nice features in C++ that can save you some time and lines of code without adding a bunch of needless overhead. Of course, there was a learning curve when bringing new people on board the project about what was/wasn't allowed for performance reasons. In general though, I see no reason why there couldn't be some subset of C++ used for kernel development other than Linus' / the kernel dev community's general distaste for it.