The problem here is something called VRAM inaccessibility.
When the LCD is on, VRAM can only be read (and written to) during short, specific periods of time.
The underlying reason for this is that most of the time during a frame, the graphics hardware is busy drawing graphics to the screen, and it doesn't allow anything to modify or access its data when it's working on it. There are only small periods each frame that the graphics controller takes a break and allows graphics data to be modified.
Being more exact, the time periods are called vBlank (short for 'vertical blanking interval') and hBlank ('horizontal blanking interval'). The first one occurs when the hardware finishes drawing the current frame, but hasn't yet started drawing the next frame. The second one happens if the hardware finishes drawing a single line of pixels on screen and goes to the next line. If graphics are actively displayed on the screen, these are the only periods when VRAM can ever be touched. Otherwise, the VRAM data sits there locked out from access.
Any write on "locked" VRAM won't do anything.
Any read on "locked" VRAM will return 0xFF, regardless of what the address really contains.
We really don't know when the code responsible for checking evolution data is going to run. It might, or might not run during vBlank. Or it might even run partially during an hBlank, and partially after hBlank has ended. It's impossible to predict - it comes down to microsecond-precise timing, which for a human player is essentially random.
So this bit of data:10 10 10 10 10 10 08 00 00 00 10 10 10 15 12 1F 12 00 00 00
Will usually end up looking something like this when read by the game:10 FF FF FF FF FF FF FF 00 00 10 FF FF FF FF FF FF FF 00 00
The 0xFF bytes are there because the subroutine tries to read VRAM data outside of vBlank/hBlank, and it ends up just reading 0xFF bytes.
The result of course comes down to timing, so it could be possible for this pattern to be shifted to a different position:FF FF FF FF FF 10 08 00 FF FF FF FF FF FF FF 1F 12 00 FF FF
I haven't tested this in more detail, but it should be possible to have this pattern shifted in such a way that the Mew evolution data could still be read. It might just take a lot of time.
I think it would be more practical to not bother trying to put the appropriate data into VRAM, and focus on making the VRAM data slide through to SRAM and try to get the appropriate data into SRAM instead (maybe there's a Pokemon that has a "01 01 15" sequence in its decompressed sprite, and if not, we can just corrupt that with 'M/Missingno. until we get it).
Edit: Was too late