The framework then needs to work with the web server -- but how? To be portable and useful, a framework it should support CGI, SCGI, Fast-CGI, ISAPI, HTTP, etc. That lots of work to do for every single framework. Big ones and little ones all need to support all those interfaces, and you know they won't. That's the whole point of WSGI: to be one single abstraction to bind all web servers to all frameworks.
If you want to write a framework, WSGI sets the bar pretty dang low. It supports pretty much everything you need to do HTTP without too many awkward quirks. You don't need to worry about how to implement a fast-cgi->nginx adapter. You just make your framework talk WSGI and plug it into existing nginx->fast-cgi and fast-cgi->wsgi libraries. Done.
WSGI was carefully designed to be as simple as possible, but no simpler. It is simple, but powerful and flexible. It's possible to write powerful composable middleware that works with any webserver and any framework, because middleware is just a WSGI app that wraps a WSGI app. Middleware can transparently add sessions, caching, compression, chunking, etc, that don't need to be tightly coupled to the framework or the webserver. So, just like WSGI can bind all webservers to all frameworks, any middleware can insert itself between any framework/webserver pair (I'm sure there are exceptions, of course). The framework shouldn't have to screw around with chunked encodings or compression. WSGI's design allows one good library to easily do that work regardless of the rest of your stack.
This article spoke about how awkward send_request() is. What it does is make it trivial for middleware to read, add, and modify headers without having to parse HTTP. Suppose you want to write a javascript obfuscator. One way to do that is to write some middleware that detects Content-Type="text/javascript" and obfuscates the response. Because of the way send_request() works, you detect javascript by looking at a variable, not writing an HTTP parser. Also, if you write that middleware for Django, it'll work unchanged when you get fed up and switch frameworks.
The whole write() vs yield vs return thing can is awkward, but it makes it easier to write a wsgi adapter for older cgi-based frameworks that respond via sys.stdout.write().
Only framework, middleware and gateway authors have to care about WSGI. If a framework author is complaining about WSGI, he or she almost definitely don't understand where WSGI came from or what problem it's really solving.
WSGI is minimal, composable, and elegant, even considering that it's backwards compatible with older frameworks. If everything supports WSGI, then everything can just be plugged into everything else without much screwing around. Composability and loose coupling are very powerful, especially at the levels of the stack where WSGI lives.
(I can see how you could get a mistaken impression from reading the discussion on HN, though.)
Armin Ronacher (who also is the author of Werkzeug) did designed something similar, called Webapi[1] and as he mentioned in the article, it's not a very good idea.
[1]: https://github.com/mitsuhiko/super-secret-wsgi-replacement
I did take a look at Werkzeug and it's one that is definitely awesome. But I think there's a false expectation that choice is bad. There's nothing wrong with Pump. It's another choice, and the response from the community was "WE ALREADY HAVE THIS" instead of "good job".
There's nothing wrong with Pump (at first glance). And instead of giving it a chance, the reaction is "no thanks". And that's sad.
The problem with that is that "your simple" != "everyone else's simple". Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer. It is a simple thing, WSGI can handle but Pump can't.
Pump is trying to replace WSGI but WSGI is a standard, if it tries to replace a standard API it has to prove that it can do all the things WSGI can do, so WSGI can be kicked to the side and everyone can switch to Pump.
So to summarize, it is ok if Pump just claimed to be a simple HTTP interface but as soon as it claims to be a better, less complex WSGI, then it starts to play the "standard" game and it show how the author doesn't really understand what WSGI is and how it got to be that way.
I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).
I was pretty surprised at all the criticisms that Pump received yesterday (http://news.ycombinator.com/item?id=2810373). The general response was defensive and critical just because it was trying to replace WSGI. However, it would seem that WSGI isn't perfect for all applications and indeed there is a place for Pump. My question is: how can we resume encouraging people to contribute? Quite honestly, if I had posted that thread and received the response it got, I would be utterly discouraged from contributing to the community in the future.