Did any computer allow overscan on a non-TV monitor?
Every computer that allowed overscan did the same on TV and non-TV.
Computer-to-TV transmission only differs from computer-to-CRT by having the frame signal modulated onto a carrier during transmission. Modulation doesn't change any part of the payload (*1) regarding timing, which, relevant for all things cumulated under 'overscan'.
Keep in mind 'overscan' is not a feature about the signal or a source, but the way it is displayed. From a display side, there is no such thing as an 'overscan'. A display only features a way of defining how much of a visible line content is really visible. Usually this setup is done external to the signal and handled manually when the display is setup.
There is as well not overscan in signal generation, as before, a line got always the same timing and thus the same amount of visible content. There is no general issue to not use all of this - except for the usual effort vs usefulness. Especially with early computer systems it is about the memory spent for image data.
It's easy to generate a full NTSC (alike) image with all content of all lines being software accessible. That's all lines and all visible part thereof. But if on average screens there are only like 80% of this signal visible (due the way it is manually set up), then why waste so much memory (and thus money) on parts not everyone will enjoy? Better fill some of the less likely displayed parts with default values and save up 20% of effort.
This even gets more important when looking at early systems whose memory wasn't enough to generate even full resolution NTSC content. Here filling a portion of the visible signal with default values not only saved memory but allowed to cramp a higher resolution with the same amount of memory.
As usual there are many ways to tackle this. And as more capable in sense of line generation a video circuit is, as more can be realized.
To generate a full spec NTSC (half) frame from a digital source and under full software control, a video circuit must provide some 262 lines with 660 pixel each, that's about 172,920 pixel, or 21,615 bytes in B&W (*2,3). Quite a lot in 8 bit times.
If we generate 22 of the lines (~9,5%) with default values (black) we save accordingly display RAM, cutting it down to 19,800 Bytes. Cutting of 20 pixels per line saves another 600 bytes - down to 19,200 and a total of ~11% less memory without loosing much visible on an average screen.
And by switching to a text storage and generate this by hardware usign lookup tables, aka character generators, we get this down to at or below a manageable 2 KiB.]
Still a lot - but it worked great so far, so why not going further by reducing lines to 200 and halving doubling the pixel, resulting in 320 per line? It gets us a high resolution picture with just 8 KiB of storage needed for display data. Cool.
Except now the number of lines lines filled with default value make it look like a letterbox screen. Not cool. By making the pixels a bit smaller and increasing the default fill left and right of the generated picture we get a nice 4:3 size again.
Now, since we already fill in some parts of the frame with default values (*4), we can as well make them configurable. Looks quite like a C64 screen, doesn't it?
*1 - Living in an analogue word, it does of course reduce the payload quality.
*2 - For simplicity this is just about B&W, considering colour would lead to a way more complex consideration without changing the basic issue.
*3 - Interestingly that's roughly what the original Mac did - a bit less pixels per line (512) but a few more lines - and blacked out corners per software to allow maximum display.
*4 - It's important to recognize this filling as default value, as it's really arbitrary and doesn't have to be black - like the ZX80 already perfectly shows :))