Let’s take a not so hypothetical scenario where a website in question has no visible cross site scripting holes in it, however it is designed to allow for multi-national users. That is, they allow for various (perhaps user defined) encoding methods. Either way the encoding methods are visible and changeable. Suddenly some of our non-obvious attack vectors are appearing more feasible.
How about this link? (Yes, I realize there are other XSS holes on this page, even though poor Jose has attempted to mitigate those risks, but bear with me). Let’s assume for a second that he had done a very good job of encoding all quotes, angle brackets or otherwise special chars. It appears to be a pretty safe function at that point. There is no other obvious way to do injection (yes I know there really is, just stay with me).
Now try the same link but switching it from UTF-8 to US-ASCII encoding (View in Internet Explorer to get it to work). Now you can see suddenly that an otherwise benign string becomes dangerous, because we have the ability to modify our encoding methods. In Internet Explorer this has now become a dangerous page (granted, it always was, but you agreed to go with me on this one, right?).
Giving users the ability to select their encoding method (by browser sniffing or otherwise) is a really bad idea as we can now clearly see in this example.