While I agree that removing the script tags is more secure, we have too many users in our environment who have added script tags to their sites using the RadEditor provider for the HTML module. In our case, removing script tags has the potential to break hundreds of pages on dozens of sites. I found out about this change too long after upgrading to roll back, so I came up with a workaround for those who are interested. If you haven't already done so you'll need download the complete source version of DotNetNuke and install it on a dev machine. Because this workaround requires changing the source code and recompiling DotNetNuke.dll I won't recommend it as a permanent solution, but it works as a temporary solution.

The part of the DNN code that strips out the tags is found in the DotNetNuke.Library project, in the /UI/Usercontrols folder in a file called TextEditor.cs. You'll need to edit the "get" method for the public property "Text", as follows:

public string Text {
get {
PortalSecurity ps = new PortalSecurity();
string filterValue = string.Empty;

// DNN 6.1 Filters out > tags by default. We don't want this behavior
// so we'll just pass back the text from the editor without modifying it.
//filterValue = ps.InputFilter(TxtDesktopHTML.Text, PortalSecurity.FilterFlag.NoScripting);
filterValue = TxtDesktopHTML.Text;
switch (OptView.SelectedItem.Value) {
case "BASIC":
switch (OptRender.SelectedItem.Value) {
case "T": return Encode(HtmlUtils.ConvertToHtml(filterValue.ToString()));
//break;
case "R": return filterValue.ToString();
//break;
default: return Encode(filterValue.ToString());
//break;
}
default: return Encode(_richTextEditor.Text);
//return Encode(ps.InputFilter(_richTextEditor.Text, PortalSecurity.FilterFlag.NoScripting));
}
}
set {
if (!String.IsNullOrEmpty(value)) {
TxtDesktopHTML.Text = Decode(HtmlUtils.ConvertToText(value))
; _richTextEditor.Text = Decode(value);
}
}
}

Once you've made that change you need to recompile your solution, which should generate a brand-new DotNetNuke.dll reflecting your changes. The final step is to copy your new DotNetNuke.dll to the bin folder of your production server and you should be able to save script tags in your HTML module. Like I said, this is a temporary solution, as you'll need to make these changes to the code every time you upgrade. 

As far as future DNN releases are concerned, I think too many users are in the same situation as we are and have too many instances of the HTML module with script tags in them to dig through and move them to the page header or a third party module. As a compromise for future releases I'm in favor of removing the filtering of script tags from the DNN source code and instead relying on the RadEditor's native content filtering. I believe it's already been pointed out that the HTML Editor configuration page allows you to create different RadEditor Settings for different Security Groups. If DNN relied solely on the RadGrid's content filtering then people could just turn on the RadGrid's native content filtering for Registered Users and turn it off for Administrators. That way site administrators could have the flexibility they need without sacrificing security. Failing that, future releases of DotNetNuke could use a host or portal setting to determine whether to filter script tags or not. From what I've seen of the code it doesn't seem like it'd be that hard to change it to check against the host or portal settings before removing the script tags. 

In any event, I hope this code proves useful to someone, and I apologize for the length of the post. I'm definitely curious to see how this issue plays out in future releases.