It doesn't have laziness nor is a functional programming language, but it does scratch that itch a bit.
Why? What are the advantages, in practice, of lazy evaluation as the default?
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...
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.
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.