Consequences of git reset --HARD on a branch that's publicly shared?

I was reading git tutorial here, where they mention:

don’t use git reset on a publicly-visible branch that other developers pull from, as it will force needless merges on other developers to clean up the history

I did not understand what the issue is. If I have a public branch with say 4 commits, A->B->C->D. D being the latest commit. If I did a hard reset back to B. Then, for other developers who've already fetched this branch, when they do git fetch again, they'll see that they are 2 commits ahead of remote, so they reset back to B and are good to right? Or did I miss something?

Except (let's say) Bob commited twice on his local, on top of D

A---B---C---D <<< shared-master, origin/shared-master
             \
              E---F <<< feature-bob

but now after a fetch he sees this :

  A---B <<< origin/shared-master
       \
        C---D <<< shared-master
             \
              E---F <<< feature-bob

So he (and everyone else) might have to resolve nasty conflicts to rebase his branch on top of B without 1) breaking his own feature, or 2) bringing back into the new shared branch parts of what was unwanted in C and D. Of course, it ultimately depends on the situation at hand, meaning that in some cases it will be easy to solve, but in the principle that's why it's something to avoid. With lots of coworkers and/or a great number of changes, this is often a big no-no in teams.