And allow each and everyone on toolserver to do XSS attacks, thus by having trust problems.
Ok, there seem to be some confusions about the security implications and the reasons for cross-site scripting limitations in the first place.
I can already devise user-JS on wikipedia which could remote control the users' browser to surf to their homebanking site in an iframe. Now if XSS were allowed I could manipulate the iframe (fill in money amounts and guessed passwords, submit forms etc.). This is NOT allowed as the wikipedia JS cannot acces pages from arbitrary different domains.That's a good thing.
Now with the reverse proxy we are not deactivating XSS entirely, we are just allowing remote controlled access to pages on one single server: the toolserver (plus we enable XHR which is very useful).
Granted, an evil user could setup another reverse proxy on the toolserver to then extend the access to other servers, but these proxied pages would appear under different domain-names (tools.wikimedia.de), so no automatic password-filling or cookies could be exploited (=no gain!). Plus it would need an opt-in user-JS component on the wiki. AND, a similar thing is already possible without the reverse proxy, by embedding a malicious toolserver iframe (not exploitable either).
I don't see how this would generate any exploitable security holes. But maybe I'm missing part of the picture?!