Much, much, much the worse is "rm -rf ~ /blue". I don't give a crap about 99% of the stuff outside of $HOME, but of course, the stuff in $HOME is the stuff that's trivial to destroy.

You're missing the point:

    $ cd dir where there are source files and temp files
    $ rm *.tmp # or so you think
    '.tmp not found'
    # too bad

Except when: (these are terrible lessons to learn)

1. You type it into the wrong system (D'oh)

2. You have run `mount --bind / /somewhere/else` then `rm -rf /somewhere` a week later

:(

I run into this all the time, too. Now my -rf usage is almost always wrapped by this:

    rmgit()
    {
        git status
        read -p "Are you sure? " -n 1 -r
        echo
        if [[ $REPLY =~ ^[Yy]$ ]]
        then
            rm .git -rf
        fi
    }

Watch it fail first, verify that the failure makes sense, check to see if there's a way to delete one file with -f before deleting the rest with -r. Use -rf only as a last resort, and only by appending the f to an already-failed command whose syntax you've validated.

do the -rf after the directory to avoid this in future

Premature enter just results in:

[web@server /]$ rm ~

rm: cannot remove `/home/web': Is a directory

Ten years prior to that, Apple had a similar bug in one of its installer scripts on OS X. I have a hard time finding much about it online now, because it happened at a time when OS X and the Internet were a lot less popular than today, but what I recall is that an unexpectedly customized installation directory (say with spaces or one level closer to "/" than the default) would cause the installer to delete a whole lot of things.