What is so bad with goto when it's used for these obvious and relevant cases?

There are some legitimate use cases for GOTO. For example for error handling and cleanup in C or for implementing some forms of state machines. But this is not one of these cases. The second example is more readable IMHO, but even more readable would be to extract the loop to a separate function and then return when you find a match. Even better would be (in pseudocode, I don't know exact syntax):

if (!in_array($ip, $ips)) throw new Exception('Not allowed');

So what is so bad about GOTO's? Structured programming uses functions and control structures to organize the code so the syntactic structure reflects the logical structure. If something is only conditionally executed, it will appear in a conditional statement block. If something is executed in a loop, it will appear in a loop block. GOTO enables you to circumvent the syntactic structure by jumping around arbitrarily, thereby making the code much harder to follow.

Of course if you have no other choice you use GOTO, but if the same effect can be achieved with functions and control structures, it is preferable.

Return, break, continue and throw/catch are all essentially gotos--they all transfer control to another piece of code and could all be implemented with gotos--in fact I did so once in a school project, a PASCAL instructor was saying how much better Pascal was than basic because of the structure...so I had to be contrary...

The most important thing about Software Engineering (I'm going to use this term over Coding to refer to a situation where you are being paid by someone else to create a codebase with others that requires ongoing improvement and maintenance) is making code Readable--getting it to do something is almost secondary. Your code will be written only once but, in most cases, people will spend days and weeks revisiting, improving and fixing it--and every time they (or you) will have to start from scratch and try to remember/figure out your code.

Most of the features that have been added to languages over the years are to make software more maintainable, not easier to write (although some languages go in that direction--they often cause long-term problems... see twitter's history with Ruby on Rails for an example).

Anyway, GOTOs can be nearly as easy to follow at their best (A single goto used in a case like you suggest), and a nightmare when abused--and are very easily abused...

So after dealing with spaghetti nightmares for a few years we just said "No", as a community we are not going to accept this--too many people mess it up if given a little leeway--that's really the only problem with them. You could use them... but even if it's the perfect case, the next guy will assume you are a terrible programmer because you don't understand the history of the community.

Many other structures have been developed just to make your code more comprehendible: Functions, Objects, Scoping, Encapsulation, Comments(!)... as well as patterns like "DRY" (preventing duplication) and "YANGI" (Reducing over-generalization/complication of code)--all really only import for the NEXT guy to read your code (Who will probably be you--after you've forgotten most of what you did in the first place!)

Nothing wrong with goto statements themselves. The wrongs are with some of the people that inappropriately use the statement.

In addition to what JacquesB said (error handling in C), you are using goto to exit a non-nested loop, something that you can do by using break. In this case you better use break.

But if you had a nested loop scenario, then using goto would be more elegant/simpler. For example:

$allowed = false;

foreach ($ips as $i) {
    foreach ($ips2 as $i2) {
        if ($ip === $i && $ip === $i2) {
            $allowed = true;
            goto out;
        }
    }
}

out:

if (!$allowed) {
    throw new Exception('Not allowed');
}

The example above doesn't make sense in your specific problem, because you don't need a nested loop. But I hope that you only see the nested loop part of it.

Bonous point: if your list of IPs is small, your method is fine. But if the list grows, know that your approach has an asymptotic worst run-time complexity of O(n). As your list grows, you may wish to use a different method that achieves O(log n) (such as a tree structure) or O(1) (a hash table with no collisions).

As others have said, the problem isn't with the goto itself; the problem is with how people use goto, and how it can make code harder to understand and maintain.

Assume the following snippet of code:

       i = 4;
label: printf( "%d\n", i );

What value gets printed for i? When does it get printed? Until you account for every instance of goto label in your function, you can't know. The simple presence of that label destroys your ability to debug code by simple inspection. For small functions with one or two branches, not much of a problem. For not-small functions...

Way back in the early '90s we were given a pile of C code that drove a 3d graphical display and told to make it run faster. It was only about 5000 lines of code, but all of it was in main, and the author used about 15 or so gotos branching in both directions. This was bad code to begin with, but the presence of those gotos made it so much worse. It took my co-worker about 2 weeks to puzzle out the flow of control. Even better, those gotos resulted in code so tightly coupled with itself that we could not make any changes without breaking something.

We tried compiling with level 1 optimization, and the compiler ate up all available RAM, then all available swap, and then panicked the system (which probably had nothing to do with the gotos themselves, but I like throwing that anecdote out there).

In the end, we gave the customer two options - let us rewrite the whole thing from scratch, or buy faster hardware.

They bought faster hardware.

Bode's rules for using goto:

1. Branch forward only;
2. Do not bypass control structures (i.e., do not branch into the body of an if or for or while statement);

There are cases where a goto is the right answer, but they are rare (breaking out of a deeply nested loop is about the only place I'd use it).

What about:

func foo(){
    foreach ($ips as $i) {
        if ($ip === $i) {
            return;
        }
    }

    throw new Exception('Not allowed');
}

There's a related question about program flow here continue and break with an extended scope.

I think when you feel program flow is getting complex enough to use a goto (which aren't completely verboten, but are generally not advised), the cleanest option often is to extract a method.

Just imho, when chosing between the boolean allowed and a goto I would probably go for the boolean. Also, I don't know your language, but there may be some kind of built-in that makes your foreach loop disappear.

In low level languages GOTO is inevitable. But in high level it should be avoided (in the case the language supports it) because it makes programs more difficult to read.

Everything boils down to making the code more difficult to read. High level languages are supossedt o make code easier to read than low level languages like, say, assembler or C.

GOTO doesn't cause global warming nor it causes poverty in the third world. It just makes code more difficult to read.

Most modern languages have control structures that make GOTO unnecessary. Some like Java don't even have it.

In fact, the term spaguetti code comes from convoluted, difficult to follow code causes by unstructured branching structures.

With the exception of goto, all flow constructs in PHP (and most languages) are scoped hierarchically.

Imagine some code examined through squinted eyes:

a;
foo {
    b;
}
c;

Regardless of what control construct foo is (if, while, etc.), there are only certain allowed orders for a, b, and c.

You could have a-b-c, or a-c, or even a-b-b-b-c. But you could never have b-c or a-b-a-c.

...unless you have goto.

$a = 1;
first:
echo 'a';
if ($a === 1) {
    echo 'b';
    $a = 2;
    goto first;
}
echo 'c'; 

goto (in particular backwards goto) can be troublesome enough that it's best to just leave it alone, and used hierarchical, blocked flow constructs.

gotos have a place, but mostly as micro-optimizations in low-level languages. IMO, there's no good place for it in PHP.

FYI, the example code can be written even better than either of your suggestions.

if(!in_array($ip, $ips, true)) {
    throw new Exception('Not allowed');
}

With goto I can write faster code!

True. Don't care.

Goto exists in assembly! They just call it jmp.

True. Don't care.

Goto solves problems more simply.

True. Don't care.

In the hands of a disciplined developer code that uses goto can be easier to read.

True. However, I've been that disciplined coder. I've seen what happens to code over time. Goto starts out fine. Then the urge to reuse code sets in. Fairly soon I find myself at a breakpoint having no damn clue what's going on even after looking at program state. Goto makes it hard to reason about code. We've worked really hard creating while, do while, for, for each switch, subroutines, functions, and more all because doing this stuff with if and goto is hard on the brain.

So no. We don't want to look at goto. Sure it's alive and well in the binary but we don't need to see that in source. In fact, if is starting to look a little shaky.

I know this is a bit off topic but if for some reason you really don't like variables and foreach and in_array is not powerful enough and you don't want to break the code out into it's own function then array_reduce to the rescue:

$ip = '192.168.1.5x';
$ips = ['192.168.1.3', '192.168.1.4', '192.168.1.5',];

if (!array_reduce($ips,function($value,$item)  use ($ip) {
    return $value || $item === $ip ? true : false;
},false)) {
    throw new Exception('Oopsie');
}
echo "Got it with no gotos\n";