Non-existent variables will always evaluate to an empty string, 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.

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.

Non-existent variables will always evaluate to an empty string, 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.

Non-existent variables will always evaluate to an empty string, 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.