After looking at the posted videos, I think that OAM layout may be the cause of the Zelda right-to-left glitch, but not the Metroid top-to-bottom glitch.
In Zelda if you frame step you can see at least one frame where the left half of Link is on the right hand side of the screen and his right half is on the left. The OAM accepts only 8 bits to specify sprite x position even though the screen is 256 pixels wide, and sprites are only 8px wide — Link himself is built out of at least two sprites. So what you're seeing is consistent with code that does something like:
set_link_sprite1(x, y)
set_link_sprite2(x+8, y)
Where x was in the range 248—255, meaning that x+8 overflows an 8-bit integer. The game logic isn't affected because Link's actual position is still safely within the 8-bit range, but setting the sprite location for his right half causes integer overflow.
In the Metroid example, Samus jumps off the top of the screen and reappears on the bottom — but not just graphically, play actually continues from there. So whatever overflow occurs affects game state. It's therefore unlikely to be a mere figment of output. I would imagine there is an internal variable that holds her position as an offset of the current screen position, and that internal variable underflows.
OAM y positions are also limited to 8 bits in size but the screen is only 240 pixels tall (224 'visible'; see comments), so portions of objects may appear to wrap if they are at least 32 pixels tall (which is two sprites, as they can be 16px tall) and drawn at a sufficiently low position with code like:
set_sprite1(x, y)
set_sprite2(x, y+16)
Or sufficiently close to the top of the screen with code more like:
set_sprite1(x, y)
set_sprite2(x, y-16)
Given that she's tall, part Samus reappearing on the top or bottom when she's close to the bottom or top would also be unsurprising.
