For TLS 1.3 (a large fraction but not majority of today's HTTPS servers) let's go step-by-step like the article:
Random: Now all 32 bytes are random
Session ID: This will now all be random if we've never talked to this server before or if we believe it speaks TLS 1.3
Cipher suites: There are newer suites [with much shorter names] for TLS 1.3 because some parameters are now fixed.
SNI: This is still there (work on Encrypted SNI which became Encrypted Client Hello is ongoing)
NEW Supported versions: Compliant servers pick the newest version they recognise from a list the client provides.
NEW Key share: A TLS 1.3 client proposes one or more (Elliptic curve) Diffie Hellman key agreements. Most servers will accept one of them.
OK, on to the Server Hello...
Random: Again all 32 bytes are random unless the server speaks TLS 1.3 (or newer) and has the impression at this point that the client does not. In this case the server overwrites a few of the bytes with the ASCII "DOWNGRD" (downgrade). A TLS 1.2 (or older) client sees no significance in this, but a TLS 1.3 client is alerted that somebody is meddling, because it's extremely unlikely that a server randomly spells "DOWNGRD" and also only knows an older protocol version.
Also, as a special case TLS 1.3 servers scribble over the entire random byte sequence with SHA256("HelloRetryRequest") if they wish you to try TLS 1.3 hello again with a different key share because all your proposals were unsuitable.
Session ID: The random nonsense from the client is echo'd back in TLS 1.3
Cipher suite: Still whichever suite the server picked.
NEW Supported versions: TLS 1.3 or better servers will echo back versions they support.
NEW Key share: Assuming the Client's proposed key shares are acceptable in TLS 1.3 the server answers with a share of their own here and then...
In TLS 1.3 and newer everything else is encrypted. Client and server have performed DH key agreement, so now they both know a random secret which they will use to begin encrypting any subsequent messages.
Certificate: is an example of something that's now encrypted. Also in TLS 1.3 the specification follows real world practice that this isn't necessarily a "chain" just one leaf certificate plus any other certificates that might help the client reach a trust decision.
The TLS 1.3 protocol is a relatively nice shape in its natural form, but what you see on the wire is spelled very weirdly because this is the only way for it to pass various rusty middleboxes and not blow up poorly implemented legacy servers out there in the real world.
Random: Now all 32 bytes are random
Session ID: This will now all be random if we've never talked to this server before or if we believe it speaks TLS 1.3
Cipher suites: There are newer suites [with much shorter names] for TLS 1.3 because some parameters are now fixed.
SNI: This is still there (work on Encrypted SNI which became Encrypted Client Hello is ongoing)
NEW Supported versions: Compliant servers pick the newest version they recognise from a list the client provides.
NEW Key share: A TLS 1.3 client proposes one or more (Elliptic curve) Diffie Hellman key agreements. Most servers will accept one of them.
OK, on to the Server Hello...
Random: Again all 32 bytes are random unless the server speaks TLS 1.3 (or newer) and has the impression at this point that the client does not. In this case the server overwrites a few of the bytes with the ASCII "DOWNGRD" (downgrade). A TLS 1.2 (or older) client sees no significance in this, but a TLS 1.3 client is alerted that somebody is meddling, because it's extremely unlikely that a server randomly spells "DOWNGRD" and also only knows an older protocol version.
Also, as a special case TLS 1.3 servers scribble over the entire random byte sequence with SHA256("HelloRetryRequest") if they wish you to try TLS 1.3 hello again with a different key share because all your proposals were unsuitable.
Session ID: The random nonsense from the client is echo'd back in TLS 1.3
Cipher suite: Still whichever suite the server picked.
NEW Supported versions: TLS 1.3 or better servers will echo back versions they support.
NEW Key share: Assuming the Client's proposed key shares are acceptable in TLS 1.3 the server answers with a share of their own here and then...
In TLS 1.3 and newer everything else is encrypted. Client and server have performed DH key agreement, so now they both know a random secret which they will use to begin encrypting any subsequent messages.
Certificate: is an example of something that's now encrypted. Also in TLS 1.3 the specification follows real world practice that this isn't necessarily a "chain" just one leaf certificate plus any other certificates that might help the client reach a trust decision.
The TLS 1.3 protocol is a relatively nice shape in its natural form, but what you see on the wire is spelled very weirdly because this is the only way for it to pass various rusty middleboxes and not blow up poorly implemented legacy servers out there in the real world.