Instead I'd introduce some sort of random failure elsewhere in the game, so it superficially looks like it's working, but isn't any fun to play...
This isn't mentioned in the article, since one of the anti-piracy/-emulation techniques I didn't discover at the time of writing it (due to my dump being an overdump) is that many of the games do this. They screw up input so it either boots but you can't play it at all, or input is unplayably slow. It detects it by having an interesting memory mirroring quirk in the cartridges that no other GBA carts have.
Mirrored memory is a side effect of unconnected lines on the address bus thus making the content of those bits irrelevant. Code can take advantage of this to run faster or put tag values into addresses.
What does this have to do with speed?
On a GBA, VRAM is faster than ordinary RAM. Programs can do well to use it for tight inner loops.
Almost all programs use IWRAM for this. It's one of the things it's for. It's as fast if not faster than VRAM (depends on if the VRAM is being accessed by the PPU at the time).
Using STM (store multiple) to DMA registers? Again, go faster.
In retrospect, yeah this might actually be the case.
Save type masquerading might be code that helps when running on a development kit, but I admit that I can't think of what use it might have.
There are a handful of GBA games that lie about save type as anti-piracy and refuse to save or even boot if it finds the wrong one. It's also really the only anti-piracy technique that any other GBA games actually use, since it's quite effective against flash carts.
This isn't mentioned in the article, since one of the anti-piracy/-emulation techniques I didn't discover at the time of writing it (due to my dump being an overdump) is that many of the games do this. They screw up input so it either boots but you can't play it at all, or input is unplayably slow. It detects it by having an interesting memory mirroring quirk in the cartridges that no other GBA carts have.