This comes from the time of structured programming.
https://en.wikipedia.org/wiki/Structured_programming
Before the structured programming paradigm people programmed disastrously, the control of the program flows arbitrarily from anywhere in the program to arbitrarily anywhere else. This caused countless problems and made it very difficult to debug the programs.
As the paradigm of structured programming emerged, the complexity of the programmes was drastically reduced. It defined the control structures (IF, WHILE, FOR, etc.) and defined the concept that
each structure should have ONLY ONE entry and ONLY ONE exit. The aim of this was to simplify things and lower the complexity (this is the holy grail).
Early on, Donald E. Knuth demonstrated that there were cases where the rule (that each structure had a single entry and a single exit) made things more complicated.
Generally, the "only one entry and only one exit" rule is a good one, and should be followed, but there are cases where a program is much more complicated when that rule is followed. My advice is. If you're a novice, follow the rules at all times, you're learning to program. If you are more advanced you can break the rule, but only when things get extremely complicated if you follows the rule and simplifies significatively if you breaks the rule.
Why the rule?
Because when you're going to review the code, or debug it, understanding its logic is much easier when you have only one entry and only one exit. The entry is at the beginning, and the exit is at the end. If you have a lot of places to go outside the structure, things can get very complicated for analysis and understanding of the code. So you must know what you're doing before you break the rule, a beginner doesn't know.
In the example you shows there are not advantages on using multiple returns, but the opposite is true, you're slightly complicating the understanding of the program. If you repeat this behavior several times, you are severely complicating the program's readinness.