I concur with everything tilly said above. To summarize, a goto is not considered harmful when you're:

• replacing the current subroutine via a goto &othersub (rare),
• autogenerating code that will never be seen or maintained directly (rarer),
• implementing a flow-of-control that Perl doesn't support natively (rarest).

For me, the key point in tilly's reply is that virtually all other "legitimate" uses of a goto in other languages are made redundant in Perl by the availability of named loops.

Whereas in C/C++ you might reasonably have to write:

    for (i=1; i<10; i++) {
      for (j=1; j<10; j++) {
        for (k=1; k<10; k++) {
          /* Process data[i][j][k] here */
          if (data[i][j][k] < threshold) goto EOLOOPS;
        }
      }
    }
    EOLOOPS:
[download]

Perl has a much cleaner way to escape from a deep nesting:

    LOOPS: for $i (1..10) {
             for $j (1..10) {
               for $k (1..10) {
                 # Process $data[$i][$j][$k] here
                 last LOOPS if $data[$i][$j][$k] < $threshold;
               }
             }
           }
[download]

Long ago, before I discovered the Way of the Camel, I used to rely on a couple of moderately evil preprocessor commands to give myself named loops in C/C++ too:

    #define named(name) goto name; name##_break: if (0) name:
    #define break(name) goto name##_break;

    /* Which then allows you to write... */

    named (LOOPS) for (i=1; i<10; i++) {
                    for (j=1; j<10; j++) {
                      for (j=1; j<10; j++) {
                        /* Process data[i][j][k] here */
                        if (data[i][j][k] < threshold) break(LOOPS);
                      }
                    }
                  }
[download]

Exploring how those #defines work -- and why they don't interfere with the semantics of normal (unnamed) break statements -- is left as an exercise for those of you who still follow the Dark Path. ;-)