That's exactly why I quoted a recent use case where an eager unzip was a win. I feel this case is common enough to justify it (and, like I say, so do other languages). And crowdsourcing these examples is kinda the point of the pitch phase.
These trade-offs are unavoidable, and worrying something might be misused, even though it has legitimate uses, is a poor reason to not put it in the standard library.
The policy currently in place with the std lib is: if laziness is unambiguously "free" (like reversed()) make it lazy by default. If there are downsides to the laziness (e.g. multiple passes would incur multiple costs – lazy.map is not just about capturing the closure), make it eager, and if there's a lazy equivalent, put that under .lazy. This would be in keeping with that.