It's important to note that Octo, while allowing us to ignore some things, does also serve as a very good platform for developing games that would run on real hardware (from the eras where such hardware existed). Even though written today, this jam does typically receives a few submissions that have been created with this intent - running at realistic speeds and with the appropriate interpreter quirks. A good number of people are fairly passionate about retro computing and enjoy this aspect in particular - myself included. Sometimes the jam has been able to have the games demonstrated on the appropriate hardware, but, emulators for the specific platforms do also exist, which allow us to verify this to some degree.
To answer your question about the HP48 display - it's a little complicated? The HP48 display is updated from a buffer in the calculator's memory, but, it is on a line by line basis & spread out evenly across the entire 'frame' time - there's eg no flip() that updates the entire display all at once. The update rate for the whole display is effectively 64Hz, however the 'next' line is drawn at a rate of 4096Hz by the CPU, interrupting away from eg the interpreter as it goes, but allowing our code to run in between. This allows us to eg turn off a sprite halfway through it being drawn.
This is not quite the same as writing directly to the screen, but it shares some of the issues. The point where the line-by-line update coincides with when you 'delay' may also strobe across the display, as we have little to anchor it in place. If you might only have a sprite drawn into the buffer for eg 10% of that 64Hz tick, that may be the cause of the issues observed.
Even if that assessment is incorrect on a technical level, the strategy proposed prior has been shown to make games significantly more playable on the HP48, besides which it's generally good advice that helps keep flickering to a minimum. If any given sprite is flickering in some way, it will significantly impact its vibrancy on screen on the HP48, as the pixels aren't super quick to respond in either direction. On the plus side, it also means doing pixel queries to the display are relatively hidden.
Well, I hope that was interesting! The jam certainly attracts all sorts so, feel free to focus on the aspects that are most appealing to you!