Yes, normal setup for TLS 1.3 always does ephemeral keys for forward secrecy first.

If some alternate protocol started by sending data encrypted with a remote server's public key this data can be replayed by attackers, just like with 0-RTT in TLS 1.3, this problem is unavoidable for 0-RTT protocols.

But where should we get a public key from anyway? If it came from a previous session, the resumption PSK is better. If we got it by guessing, maybe checking a central store of known public keys, then it might be wrong and we have to start over any time it was wrong anyway.

We have to wait to see the certificate (and transcript signature) in the normal case because until we see the certificate (and signature) we have no proof we're talking to whoever we wanted to talk to, and even if the wrong person can't decrypt the message they can replay it at their leisure.

Note that "waiting" for these is an exaggeration, in TLS 1.3 the server sends both its half of the key exchange AND the certificate with the transcript signature AND any extra metadata in a single message, it's just conceptually separate because the latter part of this message is encrypted while the first part agreed the keys for encryption, so the client needs to think about them separately.

For PFS suites with ephemeral-ephemeral DH/ECDH (DHE/ECDHE in TLS parlance) the client generates a DH key pair for each connection and so does the server; both public keys need to be exchanged before secrecy can commence.

EE-DH-based handshakes have innate entropy (due to the ephemeral keys), but TLS was initially build without EE-DH. For the historic RSA key exchange, client and server random nonces supply the handshake entropy and liveness proof; again necessitating a transmission of both nonces to the other party. RSA-KEX was removed in TLS 1.3. The nonces are always there, mostly for PSK and PSK-only handshakes (otherwise you could use PSKs only once).

TLS 1.3 resumption essentially uses a previously negotiated shared secret (PSK) which allows both parties to forego authentication-by-signature, because knowledge of the PSK authenticates them. Forward secrecy is added back in by EE-DH, but can actually be disabled.

TLS 1.3 0-RTT extends session resumption. Essentially, the early data is encrypted only under the PSK. It has neither forward secrecy (relative to the session under negotiation) nor liveness [I think it might be hypothetically possible to reject replays server-side by rejecting duplicate ClientHello.random values but this is hugely out of spec and completely negates any performance benefits 0RTT might have had].

(It's important to realize that TLS is and always has been a meta-protocol with a lot of knobs you can tweak. Now, for use in HTTPS/FTPS/STARTTLS the set of parameters is relatively restricted, because e.g. browsers simply won't support PSK-only handshakes. For general discussions of TLS properties this is something to keep in mind, however.)