This last sentence doesn't really make sense. PBKDF2 is a KDF; its whole purpose is to take low-entropy secrets like passwords and convert them into keys suitable for cryptography. That's not a jury-rigging; it's the intended function of the primitive.

If you share lots of good entropy which is secret then you can use PBKDF2 with that entropy as salt to turn bad passwords like "OpenSesame" into a good secret key.

And in that case you're right, TLS 1.3 PSKs made this way would in principle be safe because they meet the high entropy requirement. If I guess "OpenSesame" I can't guess the PSK because I don't know the salt.

But, wait, if we have enough shared entropy that's secret then we already have a suitable Pre-shared Secret Key and we didn't need to invoke PBKDF2, our design is over-complicated.

So why do people want to do PBKDF2 at all? Well of course they don't have that shared secret entropy, they were hoping "OpenSesame" was good enough and that if they can just squint hard at the PSK feature surely they can use their password for it, which is why TLS 1.3 explicitly cautions them not to do so.

What surprises people here is that there's a viable offline dictionary attack. What they tend to be imagining is that a hypothetical bad guy has to try connecting with password "Pass1234" and then try again "LetMeIn" and then again, and again, until they try "OpenSesame" and so that seems impractical.

But TLS 1.3 does afford a dictionary attack, during the unencrypted ClientHello the client sends over enough information for an attacker to confirm whether a PSK they've guessed is correct. So the attacker just collects that information, then they get to run an offline dictionary attack.

This isn't a threat for a good PSK because it's just random. You could try such an "attack" on everything else in TLS, and it would be just as (in)effective. But for a human memorable password of course dictionary attacks are a real threat because there may be only millions or even thousands of likely guesses.