From what I understand, the way TLS 1.2 and lower use DHE is an either/or affair. Either the client accepts the DHE key the server offers, or it doesn’t use DHE at all (Similar to how RSA works), if the client doesn’t support the bit length of the cert, it can’t negotiate something lower (And the server can’t know the limitations of the client)
Leads to issues where if the client only accepts weak keys (512/1024 bits) then the server can’t skip DHE, it will offer something the client doesn’t support, and if the server only offers a weak key then the client can’t ask for anything higher, it’ll just skip DHE.
In the process of overhauling everything in TLS 1.3, they’ve changed DHE to be negotiated through the same mechanism that EC stuff is currently. Instead of each server operator needing to generate their own dhparams file and what not, they’ve provided a list of fixed DHE groups that browsers need to support, and they can pick which ones to announce (And then the TLS server picks the one from that list what it wants to use).
Since it’s now properly negotiated, it can be improved upon in the future without causing incompatibilities (Since if the client only announces DHE groups the server doesn’t know, it can actually see that and not try to use it, instead of trying and failing). Of course ECDHE is still a better option (Unless you’re facing an attacker with a quantum computer), but at least they’ve fixed this deficiency.