They do: the stack frame.

That's not a closure. A closure can be persisted and retains some state, the state may or may not be mutable. What's the closure for this function in C:

  int f(int x) {
     return x * 2;
  }

There isn't one, it's just a function. This returns a closure:

  (define (multiplier n)
    (lambda (x) (* x n)))

multiplier is not a closure, it's a function, but it returns a closure which is a function closed over the environment where n is set to some value.

  (define f (multiplier 2)) ;; f is a closure

Look: I have some data and want to compute a checksum. I write code that goes through the data, does the math, and returns the result. Here the code is a function and you say it has no state; the stack frame doesn't count.

Fine. Now I want to do something else with the data AND also compute a checksum. I need to go through the data only once. So I rewrite my checksum code. I define a small record type and split my code into three pieces: initialise, add data, get the result. Now it appears I do have an object with a state, right?

But it is the same code, just a different organisation.

The difference is in the ownership and lifetime of the state used by the function. A pure function uses state that it owns or is not outlived by the mutable state it uses. Closures on the other hand uses that it doesn't own or is outlived by the state during the invocation.

The important detail here is that closures automatically moves the variable that lives in the stack frame into the heap. You can't do that with a regular function. In languages with manual memory management like C, if you try to store and use a pointer to a invalidated stack frame, you will either get a crash if you are lucky, or get a crazy bug that shouldn't happen within reason.

Your supporting and concluding statements are directed at a scarecrow though. The person you are replying to isn't contending that closures and objects are different, they are specifically saying that closures and (regular) functions has an important distinction, which I agree.

Although I would say the person you are replying to did have poor imprecise wording on their part.

An object typically has state that persists between method calls whereas a function typically does not.