Paul Graham has claimed quite a few times that OOP isn't very significant. From http://www.paulgraham.com/pfaq.html: "A lot of what seem to be OO problems turn out not to be if you have random access to the concepts that together comprise object-orientedness. If I were writing a CAD program or a simulation, for example, I'd probably use OO abstractions (though I'd probably end up creating my own OO model with macros instead of using whatever came with the language)."
I wonder, if you had 5 different Paul Grahams working on different subsystems of the same project, if they'd each create 5 different mutually incompatible object models, with no code reuse between them. How about performance? The CLR and the JVM use a lot of techniques to make method dispatch efficient; why reinvent the wheel if you need performance?
In the particular case of a serial port protocol, I could easily see how the protocol could involve keeping track of state, in which case an object would be extremely convenient. Stuffing all that into a single closure could easily become awkward; what you want is a way to manage state and behavior together, which is exactly what an object does.
Yes, objects matter more if you don't closures, because then you can simulate them using the so-called strategy pattern. But nevertheless both closures and objects are something I use frequently based on what reads easier and is easier to express.
I say this as someone who has used Lisp, who programs with map, filter, and fold all day long, and so on. I like Lisp, and also I think objects are a good idea. If you actually are working with real-world things, the ability to create a domain-model is a wonderful resource. Having a language as powerful as CLOS to work with is a blessing and I think that should be recognized, that's all.
If you actually are working with real-world things
A lot of computation involves abstractions that don't correspond to real world things. Modeling techniques aren't nearly as applicable in cases when there's nothing objective (like a chemical system) or semi-objective (like a business process) to model.
Freud said sometimes a cigar is only a cigar. Well, sometimes a function is only a function.
I worked for years on OO projects and slowly came to realize that many complex object models act like a straitjacket. They're highly coupled and thus difficult to change. This of course is the exact opposite of the benefit most often claimed for OO. It's one of the oddities of the software world that people repeat for a very long time assumptions that their own experience is contradicting. Once you've accepted a language or a paradigm as a way of thinking, you frame all problems in terms of it and you just don't see its weaknesses even when they're directly affecting you. OO was oversold way beyond its roots in simulation, partly because of the irrational economics of the software industry, and a lot of people were trained not to think about programming from any other point of view.
When a partner and I began working in Common Lisp we made a conscious effort not to take the approach we were accustomed to. For example, we didn't begin by asking "What are our objects?" We simply let ourselves follow the path of least resistance, programming incrementally in a functional style. I fully expected to end up with an object model but that never happened: we just had a lot of orthogonal functions that were easily organized in a modular fashion. Subsequent experience has borne this out, and in fact most times I have defined object models in CLOS, I've regretted it. (Generic functions are a different story.)
I'm not claiming OO isn't useful, which would be absurd as people mean different things by OO anyway. But I am sympathetic to Paul Graham's statements about objects (and also about design patterns being human compilers) because I was becoming aware of these aspects of my own experience by the time I encountered them.