I can think of several valid reasons to compile, or actually package scripts:
hide the source code
(a note of caution: it is not impossible to read the compiled code, I recommend using CPAU when passwords are involved, and even then use a temporary non-admin account with as many restrictions as feasible)
prevent users from tampering with your scripts
include a specific interpreter, so you need not worry if the right interpreter is available on the computers where the script will be running
in thin client environments: allow only certain compiled scripts to be executed instead of having to allow an interpreter and thus all scripts
a special category of packagers is that of batch files wrapped around scripts in other languages: they recreate and run a stored script in a different scripting language;
the great advantage is that you need to distribute only a single "self-contained" batch file - no installation required, and no complex command lines
Note that some packagers (e.g. Perl2Exe) include a (copy of your) script interpreter in their executable, while others (e.g. Microsoft's Script Encoder) may still require an interpreter to be installed on the target system.
As for PowerLocker and Microsoft's Script Encoder, they aren't packagers or compilers, really.
I included them because they can hide source code from prying eyes, which is the most common reason for using a packager.
Don't use the script encoder to protect administrators' passwords, or rather: don't ever use administrators' passwords hardcoded in your scripts, after all there seem to be several script decoders around...
Also note that most anti-virus software doesn't "like" compiled scripts.
On my own computer, compiled scripts are the most common source of "false positives".
Note that batch compilers may not always understand all the magic you are performing in your batch files
(packagers use the standard interpreter, so no problem there, other than batch file compatibility with Windows versions).
Use standard commands only, if possible, and forget about undocumented DOS features. Advanced Batch File Converter,
Batch File Compiler and
Quick Batch File Compiler
offer both Win32 and DOS6 compilation and handle NT's extended command switches very well,
ExeScript
(packager) can handle batch files for the default command interpreter
(NT's CMD.EXE) only, and
Bat2Exec,
BatLite and
PowerBatch
are for "real" DOS only.
I still need to test IExpress (most likely will require XP SP2 to run).
WinRAR (or any other compression software that can create executables) can be used to (un)pack and run a batch file, but it is not suited for hiding source code
