Regarding your "checklist of when it is ok ... to write ... in Unix shell:"

I agree with tye that the third bullet (process startup time) is better off not being mentioned. It's hard to imagine a case where startup time would be both so significant and so reliably favorable toward shell scripting rather than perl. On the other hand, it's easy to imagine cases where a shell script's tendency to invoke lots of sub-processes (e.g. running sed or grep inside a for loop) places it at a serious disadvantage relative to a perl script that can easily do the same task within a single process. I know you already cite this as a reason for using perl instead of a shell script -- it's just that this third item in the checklist could lead some readers astray.

Also, I would elaborate on the first item in the list: a unix environment in which Perl is not available would include (very significantly) situations where unix is being run in single-user mode, or in similarly "defective" conditions (restoring from backups, etc) where any of /usr/bin, /usr/local/bin, /usr/local/lib (and so on) are not present -- i.e. where there is nothing else but the shell (and the other stuff in /bin) for getting things done. I think this consideration will help people to focus on the appropriate domain and scope for shell scripting.

And for the shell scripts that are to be written for situations like that, it should be strongly emphasized that the second checklist item (keep it simple and short) is likely to be a matter of "life or death."