To jump backwards, there's labeled continue. To jump forwards, there's labeled break. The use case that computed goto tries to solve is addressed with labeled continue on a switch [1]
Restricted versions each covering a major use case are easier to reason about, and to optimize.
Anyhow, pretty much every version of “goto” using the name implemented or proposed for Python or other structured languages is castrated: typically, it take only a static label and has restrictions on where it can jump based on structure (out of blocks but not into blocks, within the same function, is pretty typical.)
Proper goto can jump anywhere in the program, even dynamically computed at runtime, and if state isn't set up the way the code jumped to expects, too bad. Everything more restricted is just dickering about how much it should be castrated.
These features already have reasons to exist, because they solve control flow scenarios. So there they are. And then we are brought the question of introducing goto, and there's just nothing that it adds. It would make the language more complicated for no reason.
With goto you can't know at a glance if the code is following those patterns or doing some kind of spaghetti nonsense. It hurts readability.
PHP perhaps gets honorable mention for not originally having a goto statement, but adding one something like 10 years later.
Zig moved in the opposite direction. It had one at first, and then removed it: https://github.com/ziglang/zig/issues/630