SNIP>
>It's just that I like to have my exits in the beginning or at the end; having to hunt them inside the business block of the code makes it just less readable.

I guess it depends on "having to hunt...". If you mean reading code for the joy of reading it (maybe in the throne room or such < s >) then I can see the "hunt".
But if I'm debugging some code, which always starts at the top, I get the benefit of seeing the exit right there as I read and I then know that I am done with this module and can move on to the next.
With a single exit point I have the extra added work of reading my way all the way down and verifying all of the other extraneous "lRet=.F." and their attendant "IF lRet/ENDIF".

An argument can be made, in a system that pages, that the single exit imposes a bunch of intervening code that is all effectively a NOP, adding both processing time AND the possible added bit of additional paging if a boundary is crossed and the page has aged out.

I have this opinion that 'a single exit point is the only way to go' came about when structured programming was being 'sold', back in the days when programmers wouldn't only 'exit' all over the place but would actually BRANCH OUT all over the place TO wildly different places. Now code always (well, 99 and 44/100ths of the time) RETURNs to its caller. The 'need' for a single exit point is obviated but the 'rule' continues despite it.

cheers