The other link was to a website with an emulator you could use to do the stuff from the first link. Said website also houses the main hardware documents we use for this sort of thinghttp://problemkaputt.de/gbatek.htm
Wild guess then. The game uses LZ compression and I guess you have used a tool like nlz gba or unlzgba to find and help edit.
LZ is a so called sliding window compression. It says this section for this length is the same as this section however many hundred bytes before the current location, hence the trickle down/corrupting later data effect. Pointers, while vital for hacking, may not then make the most odds with this one.
Pointers then. Games don't magically know where to look for things, even knowing what line to fetch next and where to start new ones is harder work than some devs care to program in, so you need things to tell you where to go, point the way if you will. They come in many forms on many systems but they are some mathematical relationship to the location of the data in either the ROM or somewhere in RAM. For the GBA though almost everything is visible in normal memory at all times. There are multiple locations it is seen in but a lot of the time it is in the 08000000 through 09FFFFFF region, or 08000000 through 08FFFFFF as most games are below 16 megabytes. This means people tend to look for a lot of 08 values with 3 bytes of something else* in between when looking for pointers. If you can find where the game says fetch this location you can change the pointer that did it to something else where you hopefully sorted your data if you are moving it.
*technically 08080808 is a valid pointer, even aligned to a nice address, so don't assume it has to not have something other than 08 in the middle.
Back to compression. Compression was historically the bane of ROM hacking, the thing what made it really annoying and caused the effort/skills required to shoot up. Fortunately for the GBA the BIOS of the machine housed some decompression algorithms which many devs needing such a thing actually used (or a used a compatible version of), hence you presumably being able to use a generic tool to find it. Were this the NES you would be facing something custom that a dev cooked up decades ago to run on hardware of rather limited capabilities.
I find it slightly odd that different characters (especially for a game with this many jobs) would have compression that goes over multiple sprite sheets, or maybe the compression tool overwrites subsequent ones (if you corrupt things early in the compression sequence, like say having a thing that little bit bigger and spilling over, it is bad news for later things). The multiple sheets compressed thing is not outside the realm of reason though.
Two main choices
1) Decompress everything, edit on uncompressed data, compress and try to reinsert. Possibly have to also repoint if the new data is still larger and there is nothing else you can overwrite.
2) Decompress everything, edit on uncompressed data, insert (possibly somewhere else like the end of the ROM) and get the game to simply read rather than try to decompress.
When I say everything I just mean a single instance of a compressed sheet if it is a single sprite sheet. As the compression seems known there are likely also tools to recompress it (even if you have to use good old gbacrusher) so you probably don't have to do any of the more exotic things we sometimes see; if you have an unknown compression, maybe having ripped the uncompressed version from RAM in an emulator, it can be easier to just insert a thing which says these next ? bytes are not compressed every ? bytes rather than trying to cook up a compression tool.
I occasionally see people sweat making a ROM bigger. Don't. My flash carts support SDHC memory these days and my computer has a hard drive larger still. It only mattered at the time if you were creating thousands of copies and thousands multiplied by a few pennies is still real money, or in some older flash carts of the time.