return was pretty clearly chosen in haskell to make its monadic do syntax look even more like a regular procedural language. Names that better express what return really does would be something like "pack" or "lift" or "pure".

A typical example of a confusing return in haskell is this. Note that this always prints "hi".

  foo bar = do
    if bar > 5
       then plugh
       else do
         xyzzy
         return ()
    print "hi"

Here xyzzy and plugh return different types; since the if statement needs the same type on both if branches, return has to be used to return a dummy value of the same type as plugh (here assumed to be ()). But it only returns it to the outside of the if; haskell's return does not influence control flow.

You do get used to this pretty quickly, but there's also a tendency to move away from that style of haskell. I'd write the above more like this, using guards rather than the if, and using void to force both plugh and xyzzy to return the same type.

   foo bar = go >> print "hi"
     where
       go 
         | bar > 5 = void plugh
         | otherwise = void xyzzy

I wouldn't say that that's that surprising, when you remember that 'do' in Haskell is sort of analogous to defining and calling a function inline. If you keep that in mind, 'return ()' makes perfect sense.

Return does influence the control flow in the sense that it signals the end of the monad - it's just that Haskell allows you to define and call a monad ('function') inline, which is not idiomatic in most procedural languages.

It's not too far removed from the following Python code:

> (lambda x: 5)(5)

Which, naturally, returns '5'. Lisp, of course, treats lambdas similarly; however, writing a series of statements in Lisp (like progn) is not considered idiomatic/'good' Lisp, whereas writing monads in Haskell is absolutely necessary.

Statements only make sense when you have side-effects. Having an "if statement" in Haskell wouldn't make much sense.