Most of the crummier code in N64 games is tied to partially-removed debug features. For instance, something that will read, format, and print debug info to a temporary buffer and then return without doing anything with it, or cases where you loop several times NOPping away.
Worst offender of all was Datel's GameShark, although to be fair a part of that was due to the hardware itself. Instead of using the PI to load ROM in large chunks, they copy short values using two different hardware addresses, one mirroring the upper halfword and the other grabbing the lower. These are pushed and meshed into words, and this is done for each word in ROM. Mnd you, although that is necessary for the GS's ROM, why they do it for cart ROMs is questionable.
This is especially annoying when doing a CRC calculation. To switch CRCs (keycodes) it requires loading the entire ROM one short at a time, splicing them together, calcing the checksum, then compensating for the new base value. This also happens when you upload a new BIOS, in which case it takes the BIOS you uploaded in rdram and reads it not as words but as shorts, calcs the new sum and sets it, needlessly reads its own BIOS and calculates that sum, then copies the new BIOS to hardware one short at a time and recalculates the sum again by reading it all back in. On a failure, it writes back the original BIOS and recalcs again--which is really funny since a falure to write back properly will result in it writing not the original ROM but the replacement. Naturally, they just return to the beginning of the process and read the current ROM (failed BIOS), treating the original as the replacement.
Oh, and the 'alternate hook' method will cause a permanent loop in virtually any commercial game.
As far as new code, you should see the mess that passes for reading controller input these days.