The counter is based on the following trick: whenever rendering is turned on in the PPU, it fetches nametable and BG pattern tiles from dots 0-255 and 320-340 of a scanline and fetches sprite patterns from dots 256-319, even if no sprites are visible. Because of this, if BG uses the left pattern table ($0000), and if sprites always use the right pattern table ($1000), A12 will remain low during all nametable and BG pattern fetches, and high during all sprite pattern fetches, causing it to oscillate exactly one time per scanline and 241 times per frame.

Then there are situations where response content length is not known, such as streaming over HTTP.

Last, if a certain "Accept-Content-Length" became standard, like 8MB, developers (such as those for the ad industry) would just create javascript libraries that would download large files in 8MB chunks and sidestep it.

You still need to write the logic that each layer needs to be useful.

This wasn't a big problem, because TVs of the time often had big overscan areas (areas that were rendered, but covered by the TV's physical bezel). However, it was visible on many TVs, and today it is very visible under emulation. Activision's programmers found this unacceptable. Rather than perform the very difficult, or even impossible, task of making their code run faster than the HBLANK period, they instead chose to render the first cm or so of each scanline intentionally black! Notice the width of the screen in this screenshot compared to other nearby games: https://videogamecritic.com/2600ff.htm#rev203

More crazy tricks like this are described in the excellent "Racing the Beam" book by Nick Montfort and Ian Bogost.

Some of this may have been undefined behavior, but the MMC3 chipset involved was produced and manufactured by Nintendo. Whatever the original design was, Nintendo appears to have stuck with that same set of capabilities throughout the console's lifetime, and encouraged their developers to take advantage of all the tricks.

I think there are games out there that do use sprites to do the same on the other side.

Of course, if you don't have cloners immediately nipping at your heels, you might end up releasing a smash hit that takes advantage of UB in a way that forces you to define the behavior as "it works however it needs to work to keep that game working", because eventually you yourself (the original console manufacturer) will tape out later revisions of the CPU, and you'll want to make sure they can run that game, given that it's "officially licensed" by you.

If you had the right static analysis tools in play, though, you might have wanted to run them over the game, notice the use of UB, and thus fail the game at the QA stage, before things need to escalate to that point.

You are correct thought, often guarantees about behavior can be made after the fact. Generally what happens these days is someone determines they need or want to use a certain undefined behavior. The hardware people then go, look at the RTL for the chip and confirm it behaves in a certain way, and then they UPDATE the documentation to explicitly document the newly guaranteed behavior.

Conversely, often something that is documented to work just doesn't. Especially in the case of console developers who tend to be using early steppings of custom silicon. In that case sometimes when you go to the HW team they fix it in the next stepping, sometimes they document it as errata and move on.

This doesn't preclude compromising readability for hacks when you need to squeeze performance out of some logic (just look at Tensorflow code), but you'd expect a maturing computational environment and engineering culture to reduce the number of clever hacks needed or present.

What NES cartridge from 1986 can you plug into current Nintendo boxes?