"bad practice with HTTP, such as those apps that behave the same way to GET and POST requests"
Is there a real reason why this matters? No.
For one, it matters for the simplicity of a client application. If the server implements REST properly, then all the client needs to know is the URI for the resource it's dealing with and then it basically knows that it can do a GET or a POST or a DELETE or whatever on that URI and the appropriate action will be taken. If the server doesn't distinguish between GET and POST (or the others) the dispatching to different functionality has to be done via the URI, so the client then also needs to know what URIs to hit for the equivalent create/delete/update actions.
The other problem is that if the server doesn't distinguish between GET and POST, then some client somewhere is going to use a GET for an update because, hey, it seems to work. Then a cache somewhere in between might legitimately cache it. Or you get problems like with the Google Web Accelerator that would delete all the content on a site because there are "delete" buttons with links to URIs that delete a resource on a GET request and the GWA hits them all because it ought to be safe to make GET requests according to the specs.
It matters only sometimes, and in those cases people will handle it on their own. It's counterproductive to force everyone to use programming model they don't need just so that someone else will not make a certain (well known and understood) mistake. That's B&D approach which thankfuly is not in Python or WSGI style. import this will give you a couple reasons what is.
It's not really B&D: when you recieve a request, you have to keep in mind what verb was used because each verb guarantees different kinds of behaviour. For instance, it's one thing to treat GET and POST requests identically if what you're doing to process the request fits the kind of behaviour that's acceptable in response to such a request, such as, say, displaying a page, but quite another thing if they don't, such as Anders' example of an application allowing items to be deleted with GET requests.
However, as Ian outlined, such matters are a matter for a higher-level framework than WSGI and deciding them at WSGI's level would complicate the interface between it and the application or framework sitting on top of it.
It is something that matters quite a bit, but because of HTTP itself and not some misplaced desire for B&D. It's something which ought to be in the minds of any application developer because part of developing a good application is using the underlying protocol correctly. It's nothing to do with forcing a programming model and everything to do with passing the request onto another lump of code smart enough to really know what to do with it.
I want to be clear that I wasn't disagreeing with Ian at all. I think he's absolutely spot on that the dispatching on method shouldn't be done at the WSGI level. It should be done by some layer that's on top of WSGI (I use wsgicollection for that, and it rocks).
The point that I was making was just that GET and POST are not interchangeable. They are completely different operations with different semantics. Adhering to standardized semantics isn't B&D, it's just interoperability and it lets you make simpler clients and servers.