Yes, maybe it's easier to understand what's going on once you understand the strategy in terms of a conversation. Suppose I'm Alice and I want to securely talk to Bob with TLS 1.3
The key exchange (KEX) allows me to agree a secret S with somebody I'm talking to over the network. I don't know if they're Bob, but whoever they are, eavesdroppers can't discover this secret.
Now, we (Alice, and the maybe Bob) can communicate securely with our secret S, nobody can MITM this conversation, they don't know S.
Bob sends public documents (a certificate) which say Bob knows some Private Key such that I can verify it with a published Public Key mentioned in the certificate. That's no big deal, they're public documents, anybody could have those but then...
Bob also sends a transcript. The transcript is of our KEX earlier, and it's signed using Bob's private key, which means I, Alice, can verify this is a signed transcript of our conversation. I was in the conversation, so I can confirm it's identical.
Having verified this signed transcript, I know that Bob was in the conversation I had earlier, with the unknown maybe-Bob, and it stands to reason that's because this is Bob.
Notice that if Mallory, a hypothetical MITM, tried to attack us, this won't work. The conversation between me (Alice) and Mallory must involve parameters that Mallory chose, if Mallory just forwards Bob's parameters to Alice and vice versa, Mallory doesn't learn S and so is cut out of the picture. But, if Mallory changes the parameters Alice and Bob see, then the transcript that Bob signed won't match the KEX that Alice experienced, so the connection is aborted.
Slightly stupid question but maybe you know the exact reason: could we apply symmetric encryption only after Alice has determined that maybe-Bob is the real Bob? That is only after Bob sends the certs and the signed transcript of key exchange? I'm calling this a stupid question because I see no real advantage, but I wonder if there are clear disadvantages.
If the message from Bob, proving his identity, was sent in the clear, we're needlessly telling people that Alice is talking to Bob.
In fact earlier TLS versions did send the certificates in the clear which is a lesser version of this problem, TLS 1.3 no longer does that, everything after "Hello" is encrypted.
IETF Best Common Practice 188 (RFC 7258) "Pervasive Monitoring is an Attack" says that for Internet Protocols we should assume that surveillance is inherently an atttack on the Internet and pro-actively defeat it by designing protocols not to leak information unnecessarily.
Now, in this specific case, the Hello message from Alice likely has SNI (Server Name Indication) so probably Alice is saying "Hi Bob" at the start in the clear, but (a) Not necessarily, in some cases this won't happen, so no need to tell us it's Bob later (b) There is ongoing work to fix that, Encrypted Client Hello, which will leverage DNS to give Alice keys she can use to make it harder to know, so there's no reason to make it worse.
The key exchange (KEX) allows me to agree a secret S with somebody I'm talking to over the network. I don't know if they're Bob, but whoever they are, eavesdroppers can't discover this secret.
Now, we (Alice, and the maybe Bob) can communicate securely with our secret S, nobody can MITM this conversation, they don't know S.
Bob sends public documents (a certificate) which say Bob knows some Private Key such that I can verify it with a published Public Key mentioned in the certificate. That's no big deal, they're public documents, anybody could have those but then...
Bob also sends a transcript. The transcript is of our KEX earlier, and it's signed using Bob's private key, which means I, Alice, can verify this is a signed transcript of our conversation. I was in the conversation, so I can confirm it's identical.
Having verified this signed transcript, I know that Bob was in the conversation I had earlier, with the unknown maybe-Bob, and it stands to reason that's because this is Bob.
Notice that if Mallory, a hypothetical MITM, tried to attack us, this won't work. The conversation between me (Alice) and Mallory must involve parameters that Mallory chose, if Mallory just forwards Bob's parameters to Alice and vice versa, Mallory doesn't learn S and so is cut out of the picture. But, if Mallory changes the parameters Alice and Bob see, then the transcript that Bob signed won't match the KEX that Alice experienced, so the connection is aborted.