What matters about object oriented operating systems
Many years ago, I went to a talk about a new object oriented operating system (a research project, obviously). The presenter made a big deal about how everything in, eg, their filesystem was an object, and so things were very general and you could put anything in the directory objects, and as they went on I noticed something disturbing: while you could put all those different things into directories, none of them seemed to have the same set of methods; in fact, the methods were often significantly different.
This talk led me to a conclusion: what matters in OS object orientation is not that things are objects, but what the common operations are.
If you have no common operations, it doesn't matter that everything is an object and you have theoretical generality. Your object orientation is getting you nothing in practice, because real programs have to know about the types of objects that they are dealing with so that they know what operations they can do with them.
Correspondingly, the genius of Unix is in the common operations. These make it look 'object oriented' from the outside perspective, regardless of how it is implemented internally, because almost every 'object' responds to a set of common operations.
(Current implementations of Unix kernels are almost certainly heavily object oriented internally, despite being written in C. I know that the Linux kernel is.)
I suspect that this generalizes to many object oriented programs, although I have limited experience in OO programming (especially in traditional OO languages like C++ or Java; all my OO work has been in Python). Certainly almost all of the times I've constructed object hierarchies and the like, whether in C or in Python, the driving reason has been to be able to write common operations in a generic, object type independent way.
(This is not to say that generic containers are unimportant, especially in a language.)