Can't think of any reason why this wouldn't scale reasonably well. The script simply deletes every file it can find in a loop, the only consequence of having a lot of files is that this loop runs longer. The issue is not necessarily whether the script scales, this is handled by the file system.
Now, running a WSF script introduces a more overhead than writing a straight-up CMD shell script. Regardless whether you use the script or a shell script, deleting a large amount of files is expensive and can be potentially very time consuming, so this is why we suggest that any work like this is scheduled for low-peak hours. This should be treated akin to database maintenance.
To minimize the cost of potentially large (multi gigabyte) badmail payloads, we encourage:
- Having more frequent badmail cleanup sweeps, trying to stay on top of the pile as it grows a bit more proactively.
- If you want to keep a larger amount of badmail (a few gigabytes) before sweeping, I'd suggest sweeping more with the archive functionality. Have a separate bin to dump your badmail every few days and then every so often have this bin be purged. If this is, say, another machine on your network, you can offload the cost of cleaning onto another server.
- Disabling badmail altogether (which is default in Exchange 2003 SP1, but can be done through the script).
Hope that helps!