Note also that strings passed to start_response() as a status or as response headers must follow RFC 2616 with respect to encoding. That is, they must either be ISO-8859-1 characters, or use RFC 2047 MIME encoding.
start_response is to set the HTTP headers. So I suspect that's a requirement of the HTTP spec for headers (correct me if I'm wrong).
I don't believe WSGI cares about the character set you use for the HTTP message body.
Yeah, HTTP is a byte-based protocol, and yeah, headers have to be ISO-8859-1 or MIME-encoded. But that doesn't mean that the particular bytes HTTP uses have to leak up into what are supposed to be high-level applications. There's no earthly reason why -- with every Python implementation moving to native Unicode strings -- WSGI should still have this attitude.
But everything else either has strings which are natively Unicode (and hence not byte-based in the sense we want here) or run on platforms where the underlying string abstraction is natively Unicode. This includes Jython, IronPython, Python 3.x, etc.
WSGI would like very much for those platforms to do something else, because it has to expend a bit of verbiage to basically say "shame on you for having these dangerous Unicode strings, don't you dare try to take advantage of them!"