It's pretty uncommon and it's not a deliberate debugging tool. In this case, the GBA could, hypothetically, have had a way to "park" the architecture on a game

It's pretty uncommon and it's not a deliberate debugging tool. In this case, the GBA could, hypothetically, have had a way to "park" the architecture on a game crash, or "watchdog" the system (by tying state update somewhere that should run periodically to a non-maskable interrupt that reboots the machine if that state update stops happening). Simply because it costs more to do those things, the GBA doesn't (Nintendo instead opting for the time-worn approach of the great game cart manufacturers of old, "if our games don't have bugs we don't have to worry about the behavior of the hardware in undefined state!"). So when a GBA game gets into some crash states (infinite loop with interrupts disabled, for example), the audio chip doesn't know the system is crashed and keeps doing its very simple job: reading sequential bits in RAM and converting them to sounds. Without the housekeeping that normally runs when the game is in good working order shepherding that read operation, it just keeps reading and eventually gets to the bits representing values in the cartridge ROM.