Strongly mitigated if not entirely fixed, but TLS 1.3 deployment is stalled on awful middleboxes breaking connections they have no business in, and TLS 1.2 is not nearly broken enough to see a significant exodus.
So this is what we are stuck with for the time being.
TLS 1.3 still has problems with STEKs. If you use STEKs with 0-RTT mode, then you lose forward secrecy and that's where the most sensitive data is likely to be: your request, password, credit card number, etc ...
0-RTT doesn't have to use STEKs, there's a better way to do it, but TLS1.3 won't enforce or require it (though it could), so it'll be up to the marketplace of ideas and security standards to sort it out.
0-RTT is an awful idea anyway; the equivalent of spray-and-pray. Some folks under HTTPbis are working on an Internet Draft on Early Data's (~0-RTT's) ramifications [1] in HTTP.
0-RTT trades performance at the expense of security properties inside the same tunable protocol, which is the sort of wishy-washy stuff I (and others) were hopeful we'd get away from, the same way PFS ciphersuites went from obscure to preferred overnight, the same way cleartext HTTP has been marginalized, the same way broken ciphersuites were aggressively blacklisted and underused ciphersuites were pruned.
OK, cool! In that case, I wish the article title was different, to reflect that the issues detailed in the article have all been fixed in TLS 1.3. I think it wasn't until the end of the first issue that "fixed in TLS 1.3" was mentioned.
