You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look like some permitted traffic. (Or using a different network.)
You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.
In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing.
There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired .
TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_.
A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.