... subroutines ... extra returns ...
I don't understand these points.
Certainly using multiple returns and/or refactoring code into subroutines can, in general, be extremely useful for improving the readability/reliability/maintainability of code.
But the particular code example presented in Re: Number of times I've used goto in Perl has a rather unusual structure. There are two interleaved streams of function calls and instructions:
optional functions that may be called only if no previous optional function failed;
required function calls and instructions that must all be called in order even if any previous optional function call has failed.
Using multiple returns and/or refactoring into subroutines (or even (shudder) using nested if-elsif-else blocks or conditional goto statements), it would certainly be possible to replicate the control flow of the OPed code, but again, I can't see how it would be any improvement on (anonymized user)'s basic approach; indeed, it seems to me that it could only be much worse. Can you give an example of what you envision?
Give a man a fish: <%-(-(-(-<