[endgame]

If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements.

Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen incremental streaming library or whatever. I've seen friends working in strict dialects of Haskell forced to write out each combination of list functions by hand because otherwise they'd have to materialise large intermediate data structures where regular lazy Haskell simply wouldn't.

Ed Kmett has a couple of great posts about the value he's realised from laziness:

https://www.reddit.com/r/haskell/comments/l98v73/can_you_sha...

https://www.reddit.com/r/haskell/comments/5xge0v/today_i_use...

[nrds]

What works for Kmett most often does not work for mere mortals.

As for your first point, I think it's self-defeating: You claim "you don't have to worry about libraries providing an interface to your chosen incremental streaming library", but this requires "a careful choice of implementation" in those libraries with your chosen incremental streaming semantics in mind, which is the same thing but less explicit! And as long as mere mortals can't figure out the magic implementation of `sort` which makes incremental streaming work without explicit bindings, then what's the point?

Haskell is a great language for consuming libraries written by Ed Kmett, as your link demonstrates. Otherwise, it's difficult to work with.

[endgame]

I had Ed's posts on hand, but I don't think that's true. It works at mortal levels too. If you write `map f (map g someList)`, laziness means you'll materialise at most one cons of the intermediate list (although GHC will probably fuse it outright). A strict language would materialise the entire intermediate list, and mortal developers would have to know to write `map (f . g) someList` to avoid that.

This all assumes that you're willing to buy into a language that does immutable data structures by default, and are willing to rely on the work of people like Okasaki who had to work out how to do performant purely functional data structures. If you're willing to admit more mutability (I'm not), then you sit at different points in the design space.