Shameless plug: http://engineering.hipolabs.com/how-to-work-in-a-team-versio...
I think that's a tad judgemental for two reasons:
1- because git is legitimately hard to learn. Personally I suspect git is unnecessarily hard to learn, that command names and the concepts and workflows I need are possible to learn and use with less effort. For many years people around me have been asking for git help because I know how to recover from lost stashes and use the reflog, etc., and yet I still have to google the magic incantations for commands I use regularly because they're impossible to remember.
2- There is actually a lot of value in being able to spin up a new repo instantly, in knowing that you can, and in practicing it often. Not unlike the move to VMs for development environments. Plus, there are definitely bad situations where a fresh git clone is the simpler way to go -- just not in this article. ;)
Anyway, I also agree with you because this blog post doesn't describe any truly bad situations, and because for years I've seen people blowing away their repos and starting over, and always thought to myself it was funny. It's a drastic action that takes more work than a rebase or reflog or whatever the problem was, and doesn't work well if you've made changes.
2- Yes, absolutely, it's good to remember that it's a fairly painless and easy process to spin up fresh clones. Though, if all you want is a fresh copy, in 99% of cases a "git clean -xfd" will do that for you (read the man page to find out what the options mean! man pages are your friend!). Though that one is generally a "pull ripcord in case of emergency" type of command, "git stash" generally suffices and avoids risk of losing data.
I don't recommend git stash, it frequently causes bad situations. Just branch instead, branching is safer and just as easy as stashing. Stash is not as safe as other git commands. From the man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms."
I think the nuclear option is pretty nice, since it solves every git problem I've ever heard of. All the "right" solutions only solve some particular slice of cases. Why should I be bothered to care?
There's a class of bad situations that nuke will make worse and not better. Any time you have un-pushed work, you're better off figuring out how to restore it with proper git commands than by nuking your repo. Dropped stashes or screwed up merges or rebase mistakes are all things that take some unavoidable time to learn how to fix.
Not all people who write software are full-time developers. Not all people who use git are developers at all, come to mention it. Not all people who use git for one thing use it for everything. Not everyone can justify the time required for a course for something that might be a tiny part of their work.