WSGI is _not_ a framework. It's a gateway interface, like CGI. Django is a web application framework. You don't (usually) write apps using a raw gateway interface like WSGI or CGI. You write web applications in a framework like Django or Pump.
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 agree with you, but Pump is not a web framework. You are not supposed to write your application with Pump. Picasso is a framework I built on top of Pump (https://github.com/adeel/picasso) that's more suitable for that.
(I can see how you could get a mistaken impression from reading the discussion on HN, though.)
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.