For the 3ds I am not sure of the specifics used but as you mentioned other systems it varies somewhat.
For the GBA there is no size value in the header. This makes GBA trimming run roughly "start at end of file, find the first byte that is no 00 or FF, delete from that point on". I have seen it cause issues before as some games might use a 00 or FF to end a segment which also ends a ROM. Likewise I have seen games go all the way to the boundary but have a gap at the end (some of the 32 meg titles, Riviera and Bleach if memory serves), I was later told deleting it caused issues but unlike deleting the end of most games it appeared to run. Earlier scene intros/trainers went right to the end of the file and stuck it there, this prevented trimming. The other exception would be overdumps which could occasionally go over size but not be 00/FF padded, I am not sure if there were ever any "the ROM chip is 64 mbit but the game actually uses less than 16" type arrangements but I would not be shocked to hear it.
Edit. Theoretically you could shrink a ROM if there was some extra space before the last part of useful data in a game, it would be a nightmare though even under the best conditions and fairly pointless to boot.
The DS started out using the GBA style methods. however the DS has a size value of the useful data in the header (no save though, unlike the GBA) which is usually accurate, indeed it is mostly SRL debug stuff that I see which lacks a proper value. All that said trimming to that value seems to sometimes break the download play stuff, no idea why so "safe trimming" appeared where DS roms were trimmed to the value plus a given amount.
Several games have been seen to have masses of padding between files as well, nobody really ever trimmed that (by the time ROM ripping, as in asset removal to save size, got up to speed we all had gone external memory). I recall the US version of Tetris DS has a fair bit of useless padding at the end of its sound file, the EU version did not (or it might have been the other way around) as I found out when thinking about porting the "always play classic tetris song" patch I made years back.
Iso stuff is where you might see padding shrunk between files. Most notable around here would probably be the Wii scrubber which had an extra scrubbing mode that did remove the space; there were several modes of scrubbing, some changed the iso in a manner that could not be "properly" fixed again, some changed it in a way that some theoretical AP might have been able to detect but was otherwise fine (this was the original one) and some changed it so said theoretical AP method would have to be improved considerably to test it.
Other consoles vary. There are not always size and save values and beyond that with the likes of bankswitching, mappers, extra chips and beyond it can see the size vary a bit. This is why certain NES/SNES stuff could be something other than a power of 2 value for size (though it probably would be a basic addition of a few of them), also there are dumper added headers which are often times useful to explain what it to come. Sometimes these dumper headers are useless and sometimes they are vital unless you want to do a database of all games and fingerprint every one, always be wary of someone that is overly enthusiastic about header removal.
