It's not hard to learn the difference, but the article's point in calling it a "false cognate" is just to note that there _is_ an unexpected difference. I don't believe the author's use of the phrase is correct, though. Cognates don't have to mean the exact same thing in the different languages - they just have to be derived from the same source. So a "false cognate" actually would mean words that appear to have come from the same historical roots but don't really. What makes "return" in Haskell a (true) cognate is something you mentioned - its name was chosen intentionally as a _metaphor_ for return in other languages, though it's not the same thing.
On the other hand, I think the article's point that it's tricky is valid. The way it is usually used makes it appear that it is causing the procedure being defined to exit. If a user thinks that's what it's actually doing (which they tend to do when coming from other languages), they will try to write things like "when (i == 0) (return x)", which does not mean what they think it means.
And here we have an example of a similar linguistic problem- polysemy (one expression meaning multiple things) within a single language.
In philology / historical linguistics, "cognate" is a term relating strictly to etymological origins (in which context English and German "gift" really are true cognates). In typical middle/high-school foreign language classes, though, "cognate" is usually used in the related-but-rather-different sense of a word that ought to be easy to remember for the vocab test because it's sound and meaning are both similar to a word in your own language, and a false cognate is a word that looks or sounds familiar but means the wrong thing (in which context English and German "gift" would be considered "false cognates" for pedagogical purposes). Most true cognates in the technical sense would never be presented as cognates to a beginning foreign language class.
I have heard the term "false friend" suggested as an alternative for "false cognate" but I've never seen it used except when someone is trying to talk about both.
On the other hand, I think the article's point that it's tricky is valid. The way it is usually used makes it appear that it is causing the procedure being defined to exit. If a user thinks that's what it's actually doing (which they tend to do when coming from other languages), they will try to write things like "when (i == 0) (return x)", which does not mean what they think it means.