As for exactly why: Having multiple returns means multiple points of exit from a function, which complicates the flow of control and requires you to follow more paths backwards to find state changes and final values. In general it is easiest to read and most maintainable to have a function flow from top to bottom.
By contrast http://www-cs-faculty.stanford.edu/~eroberts//papers/SIGCSE-... from 1995 does a very good job of arguing the opposite side of that. Not simply as an article of faith - but with actual data showing that internal loop and function exits make correct programming easier and more efficient. There are common problems that are significantly easier both for novices and experts to get right if you allow internal loop exits, and potentially multiple returns. (In particular the "loop and a half" problem.)
That doesn't mean that you should go crazy with the construct. You should be particularly careful with long functions (long functions are their own code smell). However judicious use of it is most certainly justifiable.
This is a little overboard, considering that I did offer support for my assertions: My own personal experience, and sound explanation. I have had to maintain code heavy with returns, and not of the sane, early-exit kind mentioned by peterhunt - deeply nested returns based on obscure logic. I didn't even know before now that there was any such "movement" around this particular opinion, however long ago, I just know that it makes sense for me and will always appear in my style guidelines.
And yes, it would be much better to finely modularize your code in the first place so that low level flow-control guidelines like this become trivial, but that's not always practical on a large team with programmers of varying skill.
By contrast in two responses, two different flows of control were presented where early exits make for more readable code. (Guard conditions and the loop-and-a-half problem.) Furthermore my personal experience disagrees with you, as does the reasoning of a fairly well thought out article that I referred you to. Which also presented pointers to research indicating that it is easier for students to produce correct code for some common problems if they have the possibility of correct code. Granted, students are generally less competent than professional programmers. However if you're concerned about varying skill on your team, why would you choose to make it harder for the poorer programmers to correctly solve problems?
Out of curiosity, what would it take for you to reconsider your style guides?
For example, if the insides of the if statements were a touch more complicated, the third could also fit the pattern of a recursive function with two base cases. We would have to read more to figure out the idea.
The first is preferable to the second because I immediately see that only one thing will happen, I don't need to look inside the if's. (Relevant if the inside is more complicated).