The reason that it works correctly in your example is that
* you have provided only one argument to `echo`, and
* you have correctly quoted your variable
That means that `echo` sees only one string to print, which is `-n Hello`, including the space in between the "words". Had you used
```
echo $var
```
without quotes instead, then `$var` would have been split at the space, and `echo` would have seen _two_ arguments: `-n` (which it will interpret as an option), and `Hello`.
This means that _in this case_, correctly quoting your shell variables is one remedy against involuntarily running into a situation where `echo` (or in fact any other command) interprets an operand as an option.
**However:**
1. Remember that the example in your linked source was printing a list of files via "glob expansion" (`*.zip`), where the variable _must_ be used unquoted, so it is not always possible to use that guard.
2. **Quoting the variables only helps in cases where word-splitting would lead to `echo` seeing an option-argument**. If the argument to be printed is a single `-n` to begin with, quoting cannot help you.
Consider e.g. a case where you have collected an array of strings that you want `echo` to print, and one of the strings happens to also be an option argument to `echo`:
```
arguments=( "-n" "Hello" )
```
Then, even if you correctly quote the variable, as in
```
echo "${arguments[@]}"
```
the first token `echo` sees will still be `-n` which it interprets as option, rather than an operand.
The same is true if you simply have several variables as arguments to pass to `echo`, and the first one turns out to be or start with `-n`. Here, too, quoting the variables cannot help you.
**TL/DR**
The key point is the term "absolutely" in the source you quoted. In most cases, `echo` will be fine. But if you start relying on that blindly, there will (sooner rather than later) be the situation in which a program you call inadvertantly mis-interprets something you intended to be an "operand" parameter with an "option" argument.