AFAIK (as someone who studies programming languages, but not as a "real" Haskell developer) the metaphor of "return" with respect to monads in Haskell is that when you "bind" a function to a monad the result (the "return value" as you might say in a many other languages) must itself be wrapped in the monad (so returning really is putting something "into" the monad).
I personally do not feel like this is squinting and rotating your head 47 degrees: if you look at simple Haskell code examples the "return" function is used in the same way as it would at the end of any normal C function. The author of this article sees it that way, but that is just an opinion in not backed up in the argument by the "false cognates" premise.
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.
do if condition
then do putStrLn "bailing out early"
return ()
else putStrLn "carrying on"
putStrLn "Launching missiles..."
This does not do what a C/Java/C# programmer would expect.
`return` in Haskell is a false cognate and it causes beginners difficulties. Some of them post to StackOverflow asking confused questions about it.
if-then-else in Haskell is also a false cognate (and there are formatting issues to trip up the unwary as well). It's actually the same as C's/Java's/etc ?: operator, so it's unfortunate the standard library doesn't contain something similar to that instead of adding if-then-else to the language.
Having said all that, I don't think being a false cognate should automatically be a disqualifying attribute. Haskell's new <> operator (a synonym for mappend) looks like Basic's/Pascal's not-equal-to operator. But I think few Haskellers come from that immediate background.
I personally do not feel like this is squinting and rotating your head 47 degrees: if you look at simple Haskell code examples the "return" function is used in the same way as it would at the end of any normal C function. The author of this article sees it that way, but that is just an opinion in not backed up in the argument by the "false cognates" premise.