Everything is driven by real-world, day job productivity. Just yesterday I sketched out how to implement EitherT to a colleague at my day job (which bans ScalaZ) - not as an abstract exercise but because he was writing some code that he could tell ought to be expressible more simply than it was.

Not being permitted to use ScalaZ really doesn't matter - this is not the first job where I've had to reimplement it and I doubt it'll be the last. EitherT is a triviality, it's a couple of lines in any language with HKT. I could write it in my sleep (and not because I'm some super-smart developer; virtually anyone who's used EitherT could). The same goes for everything in ScalaZ really, at least all the useful parts - the things in it are remarkable not for any complex logic they contain but for the lack of any such logic. In many cases once you've conceived of the type signature the implementation requires no further thought at all. (In the Haskell world they even have a tool, djinn, for generating that kind of thing). But not being able to write the thought down would be a real pain - we'd have to write longer code which would cost the client in the short term, and that longer code would obscure the important parts and be less maintainable, which would cost the client more in the long term.

I mean that's the real proof that the killer feature is not ScalaZ itself but the type-system feature - the fact that I'm willing to take a job where ScalaZ is banned, but wouldn't take one in a language without HKT.