What Jorpho said, though I will contemplate three things.
Normally when I see someone want to make an off camera area visible it involves moving it like it is a 3d world*. This is typically not a thing that is done.
*though I suppose even they have their fun. https://www.youtube.com/watch?v=kpk2tdsPh0A
10:40 or so.
Anyway started off on a tangent... I think I am getting worse.
Three scenarios I can see playing out here, or at least those things I would look at and eliminate first.
1) The game has some kind of bounds constraining you to a level despite otherwise being somewhere. 3d games will do this at their heart, though some will go further than that and border on 3). By no means a definitive test but many games will have a parallel coordinates system between what is on screen (handled by the OAM area of the GBA), the enemy/NPC/player location, animated stuff, the visual level and such. If in this glitch the player is no rendered or rendered oddly this could be what is happening.
2) The game did indeed jump you to some area of memory and it is doing its best to make a level from the data. If you are familiar with somewhat modern PC hacking techniques then think ROP (very short version is modern PC security blocks a lot, so hackers instead used things the program would allow to generate a new program as it is already in its safe area, best analogy I heard was think how a ransom note will use existing benign printed works to make something new), if you prefer older this what many a game does and has done over the years when it tries to interpret things it should not.
If this is so then most vaguely modern game consoles (of which the GBA is definitely one) will not interpret a level graphically and instead use a separate track to note the level design, enemy placement, objects... and that is often what you will glitch into, whatever happens on the visual side of things being the game still trying to make some sense of things.
Theoretically you could try to generate a visually... appealing thing from the glitch (it could possibly just be a marginal twist on classic level hacking) but it would essentially be made from whole cloth from your interpretation of matters.
3) You found some kind of developer hidden debug area, albeit one with the entrance hidden from the game's final code. Crashes might be because it tries to take items or call routines that no longer exist (the GBA is a compiled system so you can do such things far more easily than older devices), exist in that location (again compiled so if it was hardcoded to jump somewhere it might not be there right now) or make sense to the game. You could unhide this and fix the cause of crashes, might take some creative thought to figure out what the crashy bits should be, or you could just block the crash bits.
As far as "in memory" then yes but possibly not what you mean or understand from older systems. The GBA does have memory, obviously, but the carts themselves are blisteringly fast (even today they are pretty fast, hence the cost and complexity of flash carts for it where stuff like the DS was reduced to it often being more expensive to buy a swish microSD to stick in it) and are visible completely in normal memory (no banks, mappers, mbcs, pages... outside of flash carts and a couple of films that were only dumped in late 2015 https://mgba.io/2015/10/20/dumping-the-undumped/
). To that end it is essentially a bunch of read only memory (32 megabytes of glorious high speed Read Only Memory) inside the game that you can happily put a level in. Ultimately it might still be in RAM, or a snapshot thereof might be/might be streamed in but be aware of that one.
In any case I don't know if I would suggest this as a first hack, though it could be a reasonable way to start learning some assembly (you might dodge knowing some assembly for this but most likely it will require some in fairly short order to do properly).