I get that the intended use case is not paying the overhead of asymmetric crypto for embedded applications. However, that use case is already covered by something like WolfSSL stripped down to only support TLS 1.2 PSK, and they can still even use modern AEAD cihper suites like AES 256 GCM in TLS 1.2.

All of the TLS 1.3 key agreement mechanisms should have forward secrecy, even when pre-shared-keys are used. In some applications, there's too much temptation to get rid of that safety net for efficiency. We shouldn't clutter up the TLS 1.3 spec and implementations to cover that use case. Furthermore, engineers who go that route should have to explain to their boss solid engineering reasons why they're staying back at TLS 1.2. There are a small number of valid use cases for symmetric-only key exchange, but there are way more use cases where an engineer just thinks the reduced overhead is worth the risk, and their manager sees the TLS 1.3 box checked and thinks they're fine.