Clients currently need to verify all transactions before they are relayed.
Because clients don't know what block a OP_BLOCKNUMBER transaction will get into, they can't easily verify the transaction.
Workaround: Verify the transaction with the current blocknumber. When a new block arrives, kick the verified transaction back into the just received queue. Forbid OP_BLOCKNUMBER transactions from being spent with zero confirmations. To speed up reverification, the results of checking signatures could be cached.
Obviously miners know what the block number is when they try to incorporate the transaction into a block.
Any script opcodes that import state from outside can be used to fork the block chain.
It's not obvious to me that this is true. I presume that the forking mechanism relies on the clients disagreeing among themselves about the state and the transaction being structured so that this disagreement changes who gets the coins. If everyone is forever in agreement about what the outside state was when the transaction was included in the block chain then I don't see the problem. Please explain if a problem remains.
Also scripting isn't really disabled. You just have to get your new script into the whitelist and then convince some miners to upgrade. All clients will understand that new script type afterwards.
The point of scripting is to allow primitive operations to be combined in various ways to produce a predictable overall behaviour which possibly has never been seen before. Alternatively, transaction types could be hard coded to conform to specific behaviour which is well known and understood. The current behaviour is much more like the latter than the former so I think it's true to say that scripting is disabled.