Love stuff like this, I feel like I’m only ever 60% following the assembly code, so the prose explanation alongside really helps - and it’s fun to hear these ‘bugs that nobody understood or possibly even noticed until now in a classic piece of software’ stories!
One of the things I love about this era of systems is that there were none of the modern checks that we consider table-stakes in nearly everything, including most embedded systems (necessary in anything that can be hooked up to a network, and still so cheap that it's included as a nice-to-have in completely isolated embedded architectures).
Lots of reads and writes in the original NES just toggled voltages on a line somewhere, and then what happened, happened. You got the effect you wanted by toggling those voltages in a very controlled manner lock-stepped with the signal indicating the behavior of the CRT blanking intervals. Some animations in Super Mario Bros 3 involved toggling a RAM mux to select from multiple banks of sprite data so that when the graphics hardware went to pull sprites, it'd pull them from an entirely different chip with slight variations in their look. And since the TV timing mattered, they had to release different software for regions with NTSC and PAL TVs since those TVs operate with different refresh rates and refresh rate was the clock that drove the render logic.
It was a wild time.