Normally, an emulator strives for accuracy. But, since there are so few (if any) Wii and Gamecube games coming out, the library is fixed. So, I think it might be a better choice to hard-code a fix for specific games for these known crashes rather than emulating the crash accurately.

That's a philosophical question more than a pragmatic one: even if they can manually hard-code crash fixes for specific games, is the role of an emulator to provide cycle-perfect emulation or to provide the best possible game experience?

It depends on the philosophy that guides the emulation author. For example, the creator of bsnes believes in accuracy over everything. He's proud that his emulator will show the same bugs as the console when other emulators don't.

I would also add that practicality definitely comes into play. For example, there's a GBC emulator for the GBA that is written entirely in ARM assembly because that was the only way to make it run fast enough. There is a certain amount of accuracy that was sacrificed to make it work, but the fact that it actually runs games at playable speed is notable in-and-of-itself. It probably could have been done more accurately, but that doesn't really matter to most people if the games run at completely unplayable speeds, accurate or not.

One thing I always wonder about low-resource-usage emulation projects for old consoles with fixed game libraries (e.g. GBA emulating GBC), is why you can't just throw some heavy ahead-of-time analysis at the problem of statically recompiling the whole game library for the native destination architecture. Why write an "emulator" at all, when you know exactly what code you want to run, and know exactly what code that code should translate into when run on the target CPU?

I guess a potential problem would be that this requires shipping a (IP-infringing) copy of the recompiled game library with the emulator. But it doesn't quite: instead of a library of ROMs, you could just ship a library of hint files to turn the static-analysis step of the recompilation into a few seconds of work, such that you still need an input ROM and the dest-ISA program is only generated in memory.

In this case, the question is not between emulating a crash and allowing the game to proceed, but rather between emulating an abort() to land the VM in a sane terminated state, or skipping the abort() and continuing on until the emulator itself is pushed into an undefined state and crashes.