It's worth pondering the real implications of real objects as real virtual machines intercommunicating by messages (they were inspired in part by the pervasive world-wide networking that was part of Licklider's vision).
One way to think about this is that "hardware objects" are merely caches for the software objects that will embody the processes and intents.
As a cache, each computer needs a small amount of code to deal with resources of time and space and i/o to and from the net. This could be called a "micro-kernel", but in an object world, it is also objects, not a "stack". For "doing things", we can imagine a system of "real objects" residing on one or more of the hardware caches. What mix depends on the individual resources of the caches.
The wonderful Gerry Popek did a first pass at this kind of caching architecture that worked over a mixture of machine types in the 1980s -- it was called LOCUS -- and there is an excellent book from MIT Press that explains the issues and how it works.
Its main limitations were that it was made as an extension of Unix processes, but it definitely proved the concept of how this part of really distributed "objects" with cached resources worked. (I tried to get Apple to buy this system when I first got there in 1984.)
Bottom line is that there is nothing that resembles any of the huge monolithic OSs of today that "try" to make software dependent on them rather than to allow software to run everywhere and move everywhere.
So "OSs are not necessary".
(Smalltalk at Parc did not run on top of an OSs ... etc.)