Bash: What does “masking return values” mean

set MONGODB="/usr/local/mongodb/bin"

This is not a variable assignment. (It is one in C shell (csh, tcsh), but not in Bourne-style shells (sh, ash, bash, ksh, zsh, …).) This is a call to the set built-in, which sets the positional parameters, i.e. $1, $2, etc. Try running this command in a terminal, then echo $1.

To assign a value to a shell variable, just write

MONGODB="/usr/local/mongodb/bin"

This creates a shell variable (also called a (named) parameter), which you can access with $MONGODB. The variable remains internal to the shell unless you've exported it with export MONGODB. If exported, the variable is also visible to all processes started by that shell, through the environment. You can condense the assignment and the export into a single line:

export MONGODB="/usr/local/mongodb/bin"

For what you're doing, there doesn't seem to be a need for MONGODB outside the script, and PATH is already exported (once a variable is exported, if you assign a new value, it is reflected in the environment). So you can write:

MONGODB="/usr/local/mongodb/bin"    
PATH=${PATH}:${MONGODB}

Non-existent variables will always evaluate to an empty string when expanded as $FOO or (equivalently) ${FOO}, and there's no harm in depending on that, except in one particular case:

If someone has called set -u in the current shell before you try to use that variable, they've enabled this setting:

              -u      Treat unset variables as an error when performing param-
                      eter  expansion.   If expansion is attempted on an unset
                      variable, the shell prints an error message, and, if not
                      interactive, exits with a non-zero status.

This means that if you're writing a function that's designed to be sourced into a script that someone else is in control of, you may need to be paranoid about using unset variables - otherwise, if they used set -u prior to calling your function, their script would exit with an error message the first time you tried to expand an unset variable.

If you're writing your own script, there's no harm in counting on unset variables expanding to the empty string.

EDIT - Also, just a thought - since you're making the whole thing conditional on whether the terminfo color capabilities are available for your terminal, why not actually use terminfo to generate the sequences, rather than hardcoding the vt100 values? Something like:

if [ -n "$force_color_prompt" ] && type tput &>/dev/null; then
    GREEN="$(tput setaf 2)$(tput bold)"
    DIM="$(tput dim)"
    RESET="$(tput sgr0)"
fi

This may gain you some portability across other terminals (though, admittedly, the number of terminals that don't use the codes you showed is small and shrinking). It may also lose some portability, as some capabilities may not exist on some platforms depending on how correct the terminfo definitions are. YMMV.