I prefer the second way. If you always return out of a function as soon as possible, you prevent deeply nested code. This means you can forget about all the weird edge cases for most of your function, because they've clearly already returned. It makes your code easier to reason about, which is important. Here is more info.

This is something that would be SO easy to explain if you knew assembly/machine language. High level languages often hide the 'basics' of what's REALLY going on from you. That can make the task easier -- or simply APPEAR to be easier -- but it can make explaining some things harder. Another case of 'false simplicity'.

When you if (!condition) when there is no 'else' (or even when there is an else) what you are doing is basically not just testing the condition, but if the condition fails creating a "Jump past this code".

that "jump" is literally the assembly language "jmp" command (typically a JE or JNE, jump equal/not equal, or JZ or JNZ, jump zero/non-zero) which can have all sorts of penalties and overhead. It can invalidate the cache on some processors, it always invalidates any predictive execution that's going on. It can take multiple clock cycles that could just be better used to do what you really want done. On the whole it's an extra call.

... if all it is going to do after that test is return, just return... then you skip/omit that excess jump. It's called "short circuiting" out of a routine. Much akin to how boolean short-circuit evaluation will exit out once known result is found skipping anything else in the chain.

Consider if you will:

function test1() {
    console.log('ran test 1');
    return true;
}

function test2() {
    console.log('ran test 2');
    return false;
}

if (test1() || test2()) console.log('true);
else console.log('false');

Under short circuiting, test2 will NEVER be run. In an or "||" the moment any result is true, we know to continue, so the other parts of the statement are skipped to save time.

Implementing "if (condition) return;" before any other code is just manually doing the same thing, skipping out of the rest of the code we know we don't need right then and there.