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.