Reverting the working tree version of a file to match the index version is one of many things git checkout can do (depending on what args you give it).
Reverting the index version of a file to match the version in the HEAD commit is one of many things git reset can do (depending on what args you give it). It is different from the above usage of checkout in that one changes the index and the other changes the worktree. (There are other checkout operations that also affect the index; and that's part of the issue that leads to the next point...)
git restore is a relatively new command that groups these functions together, while "un-grouping" them from the unrelated things those other commands do. The docs push toward using it because it's the newer, more clear way to perform the operations it covers. The operation is equivalent; it's just new porcelain to make git more usable.
I don't know what github has to do with using one command or the other. If there's some way in which you think they're pushing restore over the others, they'd be right anyway for the reason noted above - that it's the modern way to perform those operations.