In your example, it worked correctly "by chance". The reason that is that
* you have provided only one argument to `echo`, and
* you have quoted your variable as is recommended.

That means that `echo` sees only one string as command-line argument, which is `-n Hello`, including the space in between the "words". Now, `echo` is programmed such that it recognizes `-n` as an option, but not the string `-n<space>Hello`, so it will assume that this is an _operand_ - i.e. a string you want to print "as is".

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 was a remedy against involuntarily running into a situation where `echo` 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 can only help 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.
3. **In the general case, even quoting will not help you if a program accepts arguments in the form <code>-o<i>Value</i></code>**.

 As a hypothetical case, take a program `my_formula_renderer` that typesets mathematical formulae and that accepts an option parameter <code>-s<i>fontsize</i></code>. Then, imagine you want to typeset the formula `-sqrt(a^2 + b^2)`, as in
 ```
 ./my_formula_renderer "-sqrt(a^2+b^2)"
 ```
 If your program doesn't have a `--` specifier that ends options parsing, it will think that you tried to typeset "nothing" with a font size of `qrt(a^2+b^2)`, rather than the above formula with the default font size.

 It wouldn't even help in cases where you have explicit space between the `-s` and the further formula elements, as in `"-s +2t +u^2"`; it might simply mis-interpret this as a "font size" of ` +2t +u^2` with leading space (see [e.g. this question](https://unix.stackexchange.com/q/667139/377345) where this became a problem).
4. **The same is true if a program accepts "clustering" of single-letter options.**

 As noted by @Stéphane Chazelas, `echo` for example would interpret a string `-neEenennne` as a concatenation of the options `-n`, `-e` and `-E`, so trying to print that string via `echo` would fail/behave in an unexpected way.

**TL/DR**

The key point is the term "absolutely" in the source you quoted, and the fact that it refers to `echo` specifically. 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 `echo`, or indeed another, more critical program you call, **inadvertantly mis-interprets something you intended to be an "operand" parameter as an "option" argument**, usually when you pass it as a shell variable.