I think it's fairer to compare his "real objects" to actors in the actor model. Live processes with state that can spin off new processes, send and receive messages, and change state based on the messages they receive.

Shell scripting is a subset of this with short-lived processes typically communicating sequentially via a text-based messaging system (particularly line-oriented, text-based, moderately structured data).

Long-running unix processes communicating with each other or with external processes via some other mechanism is also an example of the actor model, and consequently can each be conceived of as "real objects". But they aren't typically modeled this way or constructed around this concept, so it's more a post hoc description rather than a deliberate consequence of their design.

For "web kiddies", they deal with multiple objects all the time. Their database is an object (or collection of objects), it responds to queries by returning information, changing information, storing information. Their web server is an object responding to HTTP connections, generating session objects, which deal directly with each browser instance viewing the web content. Again, not typically modeled in this way, but it's the actor model at work.

When software is designed in this way, IMHO, it comes out better in the end. Though perhaps not as performant so sometimes we have to take those designs and drill down a bit and end up with something slightly different than the high level model.