Blockchain data is immutable, so once valid a transaction will always be valid and full nodes can verify it.
There are several reasons why I think having those would be a terrible idea.
Scalability. If scripts can access arbitrary pieces of the blockchain, fully validating nodes would require (fast!) access to the entire chain. This is currently not the case - fully validating nodes do not need the full chain, but only a small database of unspent transaction outputs (which is less than 3 GiB, and grows much slower).
Mempool management. If script validity can depend on the state of the blockchain, unconfirmed transactions can be invalidated by new blocks. It is possible to construct these hypothetical blockchain inspection opcodes so that new blocks never invalidate things (e.g. only have opcodes that fetch from a block, and if that block is not found, cause immediate script failure). However, even in that case validity may be affected by reorganizations. That would effectively mean that the entire mempool would need to be revalidated after every reorganization.
Fungibility. Related to the previous point, it is even the case that deeper-than-1 reorganizations may affect the validity of already confirmed transactions. This means wallet software would need to be extra careful about accepting payments with transactions whose validity depends on blockchain state, as reorganizations have an increased chance of wiping them out, even when the sender is completely honest. This is not true for transactions right now - transactions removed during a reorg can always be re-accepted in new blocks in the new branch.