コンパイラ言語で goto を使っても問題ない。
どうせ機械語のジャンプ命令に置き換わるだけなんだから。

ところがインタプリタ言語にとっては goto はパフォーマンスを低下させるやっかいもの。
10 FOR I=1 TO 100
20   FOR J=1 TO 200
30     PRINT "うんこ"
40     IF J=50 THEN GOTO 70
50   NEXT J
60 NEXT I
70 FOR J=1 TO 100
80   PRINT "しっこ"
90 NEXT J
仮にこのようなコードを実行するとしよう（細かいツッコミは無しね）
インタプリタは 10行目で FOR 文に出会い、変数 I と 終了値 100 をスタックに積む
次に 20 行目で 変数 J と 終了値 200 をスタックに積む。
通常は NEXT に出会ったときに終了判定がなされ、終了値に達していれば
FOR をスタックから捨てられる。
ところが 70行目で FOR〜NEXT ループの外に飛び出してしまったため
スタックには先ほどの２つの FOR 変数 I と J が積まれたままになる。
さらに 70行目で FOR に出くわしたインタプリタはどういう振る舞いをするか。
スタックに FOR J が既に積まれていないかを検査し、もしあればそれを捨てる作業が必要になる。
実はインタプリタは FOR に出会うたびに、スタックをすべて検査して、重複していないか
確かめているのだ。
GOTO 文さえなければスタックをすべて検査する必要がなくなりパフォーマンスがいくらか上がるはずだな。

java が goto を目の敵にしているのは、このせい。インタプリタにとって goto は大敵なんか長文つかれた
どうせ誰も読んでないだろなめんどくせぇもうやめたうんこちんちん！