DeViLbOi: it would break. Look at this:

a)
shortcut2 would see this:
When $evars$ are expanded only the first token of the definition is used. The line above obviously won't work. Conclusion: You must use "" in the evar definition.

b)
(same thing as a, but quotes around the Email definition)
this is what it looks like to shortcut2:
This looks a lot better but still won't work. The first "level" of quote characters is stripped when $email$ is expanded. Shortcut2 will tokenize the *shortcut line and it will try to find an executable/!bang string and a parameter string. In the example above it would assume that c:\program was the executable and that Files\Outlook.exe was the parameter string. Conclusion: You must either use quotes around $email$ in the *shortcut line OR use both single and double quotes in the $email$ definition.

c)
(quotes around everything)
the result is:
This will work perfectly (without parameters in the $email$ definition). The entire C:\Program Files\Outlook.exe string is intepreted as the executable name. The quotes from the Email definition are stripped but the quotes around "$email$" in the shortcut line still exist. Note however that any parameter like -mail given in the Email definition line would look like it was part of the executable's name.

d)
(now there's a parameter in the Email definition line)
the result is:
Single quotes work just as well as double quotes with the current lsapi. This will correctly intepret C:\Program Files\netscape.exe as the executable's name and use -mail as the parameter.

However, you should NOT assume that it is always best to use variant d). It can have sideeffects and will cause confusion, hence you should only use it locally and probably not distribute themes using d). At the moment most themes, users, and possibly even modules will assume that variant c) is used. IMO it is easier to read c) anyway.
There might be a solution for this dilemma. I can't test this right now but I think that c) would work even with parameters if LSExecute was modified to use CreateProcess instead of ShellExecute. CreateProcess reinterprets the command line it is given and can separate the arguments from the executable's name itself. !bangs with parameters would NOT work that way, but ParseBangCommand could possibly be modified as well to make even that work. The only disadvantage would be that we can't have !bangs with a space in their name. :p
I hope that made any sense. =)