End a function and return wherever it is and goes back to the calling procedure or function

-- for procedures:
return;            


-- for functions:
return value;   

Jumps around like crazy.

goto Label;            

<<Label>> 

-- but this is how you use it
--...--
if are_we_done_here then
   goto Exit_GoTo;
end if;
--...--  -- We use go to to keep only one return in the function and fast forward.
<<Exit_GoTo>>
return value;
end Use_GoTo

So if readability is your concern and not a strict "don't use goto" programming rule then you should rather use goto than multiple returns. Best, of course, is the structured approach where neither goto nor multiple returns are needed

The use of GoTo is legal if used to advance forward to the exit.

If you come from a top down approach to programming, you may have heard that "You should NEVER use GoTo" like a mantra. We could discuss this idea at length, or the Dijkstrat's paper were this all started with. Putting aside that it is obvious no one read this paper, as the only go by the publisher's title, not the content of the paper, this practice comes from the fact that many kids in high school by the 80s started with BASIC in their basements, and having acquired some overuse of GOTO by line number (which I'm not going to even try to defend). This was in the '70s. No one starts with BASIC anymore.

GoTo is the basic of Assembly programming, low-level branching, CPU/GPU optimization, many algorithms... Saying you cannot use it is like saying you have to do math without division, just because things break if you divide by zero.

As we have seen, Ada can control the errors by division with elegance, and it can also control the GoTo statement with the elegant use of Tags.

  case Operation is
     when '+' =>
        Result := Value_1 + Value_2;
     when '-' =>
        Result := Value_1 - Value_2;
     when others =>
        T_IO.Put_Line ("Illegal Operation.");
        goto Exit_Numeric_2;
  end case;
...

<<Exit_Numeric_2>>
  return;

Properly used, GoTos should move only forward (again, suggestion, not rule).

If they go back it should be under strict flow control, and probably termination clauses. Keep in mind we just made a loop.

If it goes back in an infinite loop, we should be aware of the entrance point. Why are we not using a loop? Is it necessary?

Keep in mind most usages can be established with control flow units, so why would we want to use GoTos?

Well, it avoids concurrency. Nowadays quite popular, concurrency can overload a small enough CPU.