Since I am not so experienced, could you number 2-3 possible shortcomings of not having a versioning system, apart from the one mentioned in the quoted text above?
As we develop more and more script types, each with their own default derivation path, then not having a versioning system is becoming more and more problematic. It's why wallets such as Electrum have implemented a feature to scan all the commonly used script/path pairs for BIP39 seed phrases, because many users do not know where exactly their coins are stored and many wallets do their own thing such as derive P2WPKH addresses at m/44'/0'/0', use m/0' instead, and so on.
1. I see. It looks there's major trade-off between preserving backward compatibility (not many things could be added) or breaking backward compatibility (less adaption/usage).
I don't think so. OP's proposal as it stands is 100% backwards compatible. If I generate a new 15 word seed phrase with the 32 bit versioning system, old wallets will still see the entire seed phrase as a valid BIP39 seed phrase and will recover the exact same wallets (provided of course I know my script type/derivation path, since old wallets won't be able to interpret the 32 extra bits). Any legacy seed phrases will still be recoverable by new wallets, provided there is a simple check box to indicate it is a legacy seed phrase so the software does not try to interpret the first 32 bits of entropy as versioning data.