It argues that you can achieve a certain useful separation between programs together when one produces data for the other.

This can be achieved in a very satisfactory way with explicit streams (i.e. lazy lists). It can be satisfied with delimited closures, coroutines, threads and often with lexical closures. Not to mention Icon-style generators.

Lazy lists can be incorporated into the language so that their cell are first-class objects and substitute for regular eager cells smoothly. (Thank you, OOP).

The paper is actually wrong there, because laziness alone will not provide the kind of separation that g can begin executing, such that f then only executes when an item is required. Not for an arbitrary f! Suppose f traverses a graph structure recursively and yields some interesting items. Lazy eval alone isn't going to allow the f traversal to behave as a coroutine controlled by g, proceeding only as far as g continues to be interested in further items. The author is attributing to lazy evaluation magical powers that it doesn't have.

Laziness has precise semantics which has to unfold properly, or else things don't work.

Delaying evaluation is not the same thing as delaying reclamation. They are opposite in a sense, because we only allow something to be reclaimed when it is "of no value".

To what degree do you use Lisp as an FP language? As a pure FP language? The forced purity may make Haskell a very different language.

And, to return to your original complaint: If you dislike new languages, I bet XML drives you straight up the wall...

there is the famous example of the reddit founders, who believed pg's lisp story, and built the first version of their site with it. it went so badly for them that they had to start over again in python.

... but i bet you are going to have a very plausible-sounding reason why it didn't work for them.