Sometimes, it's really hard. Using the reflog is like looking through a pinhole.
When recovering from a bad merge conflict, you have a bunch of commits in your reflog which have the same name, and you need to decide which one you want. It's hard to look at the exact diff data and decide which one is appropriate.
It's not listed in the article, but it also enables a workflow where you check out parent commits many times along your branch of development and start new offshoots, and possibly amend commits with many descendants. It becomes nigh impossible to manage the reflog when there are so many commits with the same message but different content. The reflog itself also doesn't make it easy to recover lost descendant commits, only the given root commit.
Other scenarios: the reflog will not help recover where a deleted branch pointed to, and it won't help update multiple branches that pointed to the different positions in the same rebased stack of commits (the reflog for HEAD, anyways).