I think it is fair to criticize Dispatch in the following sense: "is this a library you should use in production code?". I think the answer is no, because it has an API that, while terse, is difficult to read and maintain; and furthermore it pays very little attention to robustness performance concerns (like failure accrual and more sophisticated connection pooling) that quickly become important in production software.
Dispatch is a good example of a library that is more fun/pretty than practical for systems engineering -- which is not uncommon in the Scala community, as Coda rightly points out. It's not bad to be fun/pretty rather than practical, but it is right to criticize that (strongly) from an engineering perspective.
I'm biased, but: Finagle has a substantially more robust HTTP client and server library than Dispatch, and it has been stressed at far larger deployments than Dispatch. If you're writing a high-performance system that needs to make tens of thousands of HTTP requests per second, Finagle is a good choice and Dispatch is not.
Finagle is a great library. We were able to pretty quickly write a HTTP load-testing tool; features like failover and retries give the impression that it's a battle-tested library.
However, like all the Twitter Scala libraries, it's currently stuck at 2.8.1 (2.9.0, the next version, was released May 2001). Most new Scala libraries are only being released for 2.9.x, meaning that most developers are forced to make a choice between using Twitter's libraries or other, newer ones.
Further, there are several outstanding pull requests on GitHub to add 2.9.1 support. It was relatively trivial to update the libraries to 2.9.1, but they're not getting integrated. I haven't gotten any feedback about when these might get merged, or why Twitter is stuck on 2.8.1. I've heard through third parties that this is due to problems with Java interoperability with 2.9.1. Also, the custom SBT plugins used seem to, for some reason, break SBT's ability to cross-build.
Unlike with Ruby gems, using forked dependencies is non-trivial.
I intend to keep using Scala. This problem, however, is representative of the relative lack of maturity of the Scala ecosystem. I hope and anticipate this will be resolved in the future. As of now, they represent real problems that get in the way of delivering working code.
Dispatch is a good example of a library that is more fun/pretty than practical for systems engineering -- which is not uncommon in the Scala community, as Coda rightly points out. It's not bad to be fun/pretty rather than practical, but it is right to criticize that (strongly) from an engineering perspective.
I'm biased, but: Finagle has a substantially more robust HTTP client and server library than Dispatch, and it has been stressed at far larger deployments than Dispatch. If you're writing a high-performance system that needs to make tens of thousands of HTTP requests per second, Finagle is a good choice and Dispatch is not.