IMHO tracking deployment height and applying different semantics to a contract on that basis has drawbacks. It means that if you have deployment transactions, they might produce different results if you cross the hardfork boundary. Although this is technically true already with gas schedule changes, this seems much more likely to cause issues. This is also true if you work in an Osaka environment and then switch networks. And we haven’t addressed contracts creating contracts which could also be messy. By contrast, versioning seems more elegant and allows explicit opt-in.
That does not mean that all of EOFv1 belongs as a bundle together. In fact it would be possible to introduce versioning on its own and nothing else, but there would be no incentive to upgrade. If we want a carrot, a good choice would be stack validation + relative jumps, which enable optimizations that could enable a gas discount. This pulls in roughly half of the EOF EIPs, which constitute a more minimal set and exclude some of the more problematic changes like gas inobservability. This may be inaccurate because I haven’t been following EOF closely, but the message is: versioning per se uniquely unlocks a more efficient EVM afaict.