Adding another data field in the transaction has a very high level of resistance to overcome, all of the client tooling would need to change to support it.
As for people using bytecode to store data, that is exactly the problem that this EIP is aiming to solve. Without clear deliniation about what is code and what is data we can’t make reasonable conclusions about the contract code. Just because some contracts started abusing the contract data should not preclude us from using the field as intended and to curb that abuse.
And I feel that the bytecode is a very good place for the versioning information. The JVM, CIL, WebAssembly, and LLVM bitcode all use items like magic numbers for headers, in stream metadata, and explicit versioning in their data files. This is in line with how modern VMs operate