Maintainability.

You can't read a block of code and as quickly and understand its control flow without reading every line, especially in regards to resource cleanup.

For example say you have:

...
if this:
    something
    or other
    and many more...
    ...
else:
    yet another thing 
    and some more
    ...

do some cleanup
return
...

Say you aren't exactly interested in what happens inside each branch. If you can assume that there's one return at the end of the block, you can see the if and else, you can reason about what values would trigger each branch, you can also see that no matter which branch is executed, the cleanup step will be executed before returning. Straightforward. I don't have to read all the lines of the branches to ensure the cleanup will be executed. If I can't assume a single return, I have to read all those lines too to ensure none of them jumps out of the function skipping the cleanup. Not having to think about such cases reduces the amount of reading needed and it makes reasoning about the block simpler. The bigger the blocks, the more the branches, the stronger the effect. You have one less foot-shotgun to think about. The easier you make it for your brain, the fewer mistakes it's gonna make. For all those days when you haven't slept enough.

E: Oh also refactoring blocks of code out into functions is trivial when you don't have multiple returns. Extracting a block with a return in it breaks the parent control flow and requires changes in the implementation.

E2: Shorter blocks do not obviate this argument. They just make things less bad. But they make almost everything less bad. Shorter blocks and single returns make things even better.