What you said above is misleading. Mutability is not inherently tied to OOP. You can have immutable objects just as much as you can have functions that manipulate mutable state that they hide. I have heard that some people have even proposed in the past that one be allowed to access the variables a closure has a reference to outside of the body of the closure itself. How's that for mutable functional programming?

To me, the biggest advantages of OOP are composition and sub-typing. Check out PLT-Racket's concept of an iterable versus that of most OO languages (http://docs.racket-lang.org/reference/sequences.html#%28def....). In PLT-Racket you have to bundle together a list of functions, essentially rolling your own v-table from scratch. In an OO language you have this nice packaged concept of an Iterable interface, which is much easier to understand conceptually.

Underneath the hood, both are doing the same thing; both are performing operations according to a specified interface for some underlying data that the consumer knows nothing about. This is encapsulated message passing, which is at the heart of the OO. The same sort of thing can be done with immutable objects like functional data structures (http://code.google.com/p/pcollections/). OOP and functional programming need not contradict one another or be mutually exclusive.

As a final note, no one codes in lambda calculus any more than anyone codes in Turing machines. Real functional languages have mutable variables, and Haskell is the only language that I am aware of that tries to hide this fact as much as possible.