Huh! Check this out...
I thought I'd be clever here. Since Replace() works, it appeared at first that using expressions in Rename, Move, and Copy somehow avoids the disallowed characters check. Now, this actually could be dangerous if it were true, because you could then feed it actual disallowed characters. But that doesn't appear to be what's happening. Instead, there seems to be some special handling of the Replace() expression explicitly.
Anyway, at first I thought I'd be clever and just use If(1,[Renamer Directories]) to "protect" the rules from having their \ characters stripped. It dawned on me that this might not be a good idea, but I wanted to try it out anyway. It didn't work, the characters still get stripped. But, I found some really weird behavior of the If() expression, so I thought I'd mention it.
To reproduce this, follow these simple steps:
1. Create a new calculated field called [Test] with this as the expression:
[Media Type]\[Media Sub Type]\[Series]\[Season]\
2. Find a file that has a [Series], [Season], and [Episode] tagged, and then open the Rename, Move, and Copy tool on that file.
3. Paste If(1,[Test]) in the directories box. The output from this expression is always "1". If you paste in If(2,[Test]) then the output is always "2". It shouldn't be that way, since 1 is the test, and 1 is always true.
4. Now, paste in this instead If(1,[Test],0). This works like it should (it outputs the results of the [test] expression except that it strips the "\" characters).
For some reason, this particular If() statement, when used in the Rename, Move, and Copy Tool (at least) seems to require a negative result parameter to work properly, even though that parameter is supposed to be optional.