From a graphical perspective, the AI wouldn't care at all - it's looking to match what it knows the screen looks like (e.g. the next piece shown) with what it knows about the game, so whether it's technicolour or NES colour, it doesn't matter to an AI.
But keeping the gameplay identical down to the frame by frame behaviours should be relatively possible without too much drama.
I suppose the biggest question is at what point you start running into limits in counting; a 4 byte (32 bit) number holds a score of 4 billion without loss of accuracy, an 8 byte (64 bit) number gets you to 18,446,744,073,709,551,615 without loss of precision. 16 byte number (128 bit) gets you to something north of 3*10^38 (imagine a 3 with 38 zeroes after it) without loss of precision, and I think you're more at risk of the game taking an exponential amount of time to reach those sorts of scores, but it's fascinating to think about.
The question really becomes at what point you're prepared to change the rules of the game to see what the limits really are - the speed of the game at this level is bounded primarily on rendering and input speed; the AI doesn't get access to the internals of the game to see what the next piece is, it has to wait for that first frame showing it. Similarly, it's bounded by the input resolution of - what was it, 12 Hz? That's the maximum speed input is *allowed* into the game, but there's no reason why you have to keep these metrics bounded to actual time.
If you decouple it from *actual* time and simply do it as a series of frames that can be reviewed/played back at any speed, your ability to crunch frames is now significantly faster because you don't have to wait for the time to occur between frames for the frames to happen.
You could model 'here are the 30 frames in second 001, with the following inputs being applied on these frames' and play them back in real time if you wanted, at which point you could let it run as fast as it can be computed; the 30 frames for second 001 might not take a second to be calculated especially with modern computing hardware.
I'm reminded of some of the stuff in the DOOM speedrun arena where the runs are recorded in such a way that the states and keypresses per frame are recorded so they can be played back perfectly and watched for signs of tampering - there's no reason something similar couldn't be done for Tetris, but it looks cooler to do it with a simulated NES