I answered here. I linked the paper by McCarthy at the end.
Contrast this to procedural or object oriented programming where usually the parts know a lot more about the context (state) than they really need to know. This can lead to implicit (and hard to discover) assumptions about the state of the world that are broken later on when some parts are changed, leading to bugs.
The way this works is by combining functions with (higher order) functions. For example, chain a function that gets A and returns B with a function that gets B and returns C. This is done without ever speaking of concrete inputs - reducing unnecessary knowledge should lead to fewer bugs. (Whether that's a more practical approach is another question).
Lisp is not only where functional programming originated, but also object-based programming leading to OOP. Lisp was the first language which had first-class objects: encapsulated identities operated upon by functions, and having a type.
For instance, an object of CONS type could only be accessed by the "getter" functions CAR and CDR which take a reference to the object, and by the "setters" RPLACA an RPLACD.
Meanwhile, the other higher level programming language in existence, Fortran, had just procedures acting on global variables.
There are other places in the Lambda papers and whatnot where they talk about objects, but I don't recall seeing that exact phrase. Of course, just what they meant by it is another question.