The issue lies with servers that do not adhere to the standard regarding version negotiation. Your proposed solution (the 'insecure fallback') is about making a client deal with this in a way that is insecure when TLS 1.2 is insecure. Our proposed solution is to change version negotiation so the faulty servers continue to work.
As you noted, 1.2 is still secure. So at this moment, we don't need 1.3 (save for the advantages like 1RTT handshakes). Thus there is no security benefit to adapting 1.3 earlier.
Now, if 1.2 ever becomes insecure, insecure fallback means MitM can force 1.2 and then attack, even if both server and client are willing and capable of using 1.3. It is true that when 1.2 is insecure, neither clients nor servers should be willing to use it. However, slow updating or 'compatibility' might see servers and clients still support it. It is those servers and clients that are vulnerable under insecure fallback. Under normal version negotiation the only weak systems are those that only support 1.2 (presuming higher versions are secure).
Thus, if 1.2 were broken, insecure fallback leaves more legacy systems vulnerable than normal version negotiation does.
In my personal opinion, non-compliant servers are broken, and we should not try to support them. But I understand how reality makes that infeasible.