The reason is backwards compatibility. If we suddenly turn on 1702 and require all code to be validated suddenly contracts that could be submitted the block prior now fail to deploy. And such bad opcodes comes from widely used option in solidity (some of which may even be the default, I’d have to research that).
That’s bad UX, we need to provide some sort of a means for a contract deployer to “opt in,” and in time the tooling will default to opting in and provide options to opt out. We could just do the header (using 0xef as the version header) that required validation at deployment time. But the impression I got is that other core developers would want a flag to indicate that validation has been/could have been performed other than just the content of the contract.
So if we had to choose one it would be the 1707 variant. That preserves the ability of tooling to ease into the new requirements.