[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.