One of the original reasons was to make it easier for server authors writing C code to interface with WSGI.  C APIs that operate on lists and dicts often do not do what you would expect, when called on a subclass.  Essentially, this could lead to an app that appears 
to work correctly on one server, but breaks strangely when run on another.

(IOW, Python's C API and built-in types often break the Liskov principle: there are C-level operations that don't call back into Python subclass methods, so overriding just a few methods usually doesn't work as expected.)

Another reason was to avoid having to document precisely which methods of a str, list, etc. are required to be implemented.  (This is somewhat easier now that we have abc's, but really, it's still a royal PITA.)

In any event, it's entirely moot now, six years later.  Any change requests should be sent to the Web-SIG for WSGI 2.0 discussion, as changing the existing PEPs is not an option.  (Guido has pronounced that I cannot change PEP 333 in any way, so even if I agreed with the requests in this thread, there is simply no way that wsgiref is changing in 2.x.  PEP 3333 has just been approved as well, so the odds of even a 3.x change are low.  But as I said, I won't object to a Headers patch that *converts* its non-conforming inputs to objects of type str, as long as they were stringlike objects to start with.)