Shell – What does su – `whoami` command do

I think you're confused about terminology.

An "environment variable" is merely a shell variable that any child processes will inherit.

What you're doing in your example is creating a shell variable. It's not in the environment until you export it:

MY_HOME="/home/my_user"
export MY_HOME

puts a variable named "MY_HOME" in almost all shells (csh, tcsh excepted).

In this particular case, the double-quotes are superfluous. They have no effect. Double-quotes group substrings, but allows whatever shell you use to do variable substitution. Single-quoting groups substrings and prevents substitution. Since your example assignment does not have any variables in it, the double-quotes could have appeared as single-quotes.

V='some substrings grouped together'  # assignment
X="Put $V to make a longer string"    # substitution and then assignment
Y=`date`                              # run command, assign its output
Z='Put $V to make a longer string'    # no substition, simple assignment

Nothing is in the environment until you export it.

The ! character invokes bash's history substitution (enabled by default in interactive shells). When followed by a string (as in your failing example) it tries to expand to the last history event that began with that string. Just like $var gets expanded to the value of that string, !echo would expand to the last echo command in your history.

Space is a breaking character in such expansions. First note how this would work with variables:

# var="like"
# echo "$var"
like
# echo "$"
$
# echo "Do you $var frogs?"
Do you like frogs?       <- as expected, variable name broken at space
# echo "Do you $varfrogs?"
Do you?                  <- $varfrogs not defined, replaced with blank
# echo "Do you $ var frogs?"
Do you $ var frogs?      <- $ not a valid variable name, ignored

The same thing will happen for history expansion. The bang character (!) starts off a history replacement sequence, but only if followed by a string. Following it with a space make it literal bang instead of part of a replace sequence.

You can avoid this kind of replacement for both variable and history expantion by using single quotes. Your first examples used single quotes and so ran fine. Your last examples are in double quotes and thus bash scanned them for expantion sequences before it did anything else. The only reason the first one didn't trip is that that the space is a break character as shown above.