I believe that the first example is better than then 2nd.
Why? Because it is easier to understand. It wins hands down - with no doubt at all in my mind - but obviously you have some doubts.

Clarity should be the key thing, not conformance to some arbitrary "coding style rule".

The "rules" about things like "no multiple returns" have to be taken in the context of the "art of programming". Judgment is required.

Option #1 has 10 program statements aside from boiler-plate, 3 of which have a return value or about 1/3 of the statements send something back to the caller (produce a result).

The arguments against having multiple return statements are the same as the ones against the "go to". But this is a bogus argument if you have a function that is expressed in some dozen lines or say 1/2 page and it has a very clear purpose and a very clear return value.

The "go to" is deadly when it jumps to widely separated parts of the code. That's not what we have here!

I just don't buy the argument that you are going to modify a 10 line (or even 1/2 page) subroutine without understanding what those 10 lines do!

Calling a sub that has multiple return points can simply the overall code's logic and increase the maintainability of the code. Reducing the level of indenting is a huge factor in clarity. Clarity is a good thing, not a bad thing.