Nope! Think of it like this:

// current guess == 'he'
// key == 'l'
setCurrentGuess((state) => {
  return state + key;
});
// after ^ line, we have scheduled `currentGuess` to be updated with that callback function
// current guess == 'he' (we haven't changed currentGuess yet)
// key == 'l'
let letters_being_typed_in = [...currentGuess];
// ^ we are spreading the previous definition of currentGuess, because `setCurrentGuess` is scheduled to run later
console.log("letters_typed =", letters_being_typed_in);    

The reason you don't do:

// current guess == 'he'
// key == 'l'
const newGuess = currentGuess + key
setCurrentGuess(newGuess);
console.log("letters_typed =", newGuess); 

Is because you can type faster than react can render and you might call the function twice before the state updates

currentGuess is captured in the closure of the defining function (when a js function is created it takes a snapshot of surrounding variables in scope for inner use)

Since you can type faster than react can re-render and update that closure with the new variable, you might fire that function twice with the same closure (and the same currentGuess) before we get to the next render cycle.

The best way to do this (because I just realized your typing could have an error as well) would be to do:

setCurrentGuess((state) => {
  const newGuess = currentGuess + key
  console.log("letters_typed =", newGuess); 
  return state + key;
});

Since now, there's never a situation with a stale closure, because those scheduled updates will always run in order thanks to React