That would be good advice in that situation. Certainly, allowing people to believe that they can "pick up" programming knowledge without working hard at it would be irresponsible. Telling someone the truth about their work is generally a good idea. You can easily do this in a helpful, non-mocking way, so I don't really see the conflict here.
The OP linked to the Hacker School Rules, which state that people should not be humiliated for their lack of knowledge. These rules say that the following responses to encountering an inexperienced person would be wrong:
"omg, you call yourself a programmer but you don't know how to write a thread-safe hash map?"
"well, actually, if you knew how to use git properly you would have done a rebase there"
"you're using MegaTest? everyone knows SuperDuperTest is the best testing framework, use that instead"
Those are all unprofessional and unhelpful things to say. In contrast:
"that's OK, concurrency is pretty hard. if you want to learn more about it, I can give you some pointers but you probably want to build up your knowledge a bit more before attempting this."
"ok, let's take a look at the git log now. you see how the history has some of your 'figuring stuff out' commits in there? well, there's a way of tidying up your commit history before merging it in - there's this thing called rebasing, which we can use to make our history easier to understand. here's a good tutorial on it - give me a shout if you need some help"
"the MegaTest library is OK, but it's not that well-maintained any more and quite a few people have migrated to SuperDuperTest. there's a really good post about the differences here, and you might want to pick that up for your next project"
Obviously, these are caricatures to some extent. But the point is not that people who are getting stuff wrong should not be corrected, the point is that there's a good way and a bad way to correct them, and choosing the good way makes the world a better place for everyone.