Michael,
You're correct that most modules assume that if someone can edit them, they are in a position of trust, so their input is not usually filtered. Exceptions are modules that are likely to have anonymous user input, or have many users in a low privileged position having input e.g. blogs/forums are good examples.
We had considered filtering all user input from all tangents before, but it was a very large job, and also, oddly enough, not a standard portal practice (if you evaluate other CMS products you'll find that they operate a similar policy where anonymous points such as login/registration etc. are tightly controlled, but in areas where a username/password is required to gain access theres less restrictions - theres also the fact that forcing filtering can impact functionality eg. should you filter the text/html module?). Now that all the modules are decoupled, it's somewhat up to each project group how far they wish to constrain user input (using the core InputFilter method is the recommended practice)
As a core level protection against XSS we did add support for HttpOnly cookies in 3.2/4.0 (see http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/256/Default.aspx for more details)
Cathal