At the time CRTs with square corners became a thing in the mid 80's, PAL TVs would generally display almost all of the signal.
And American TVs from the latter half of the 80's also tended to cover up less of the overscan with their bezels, but home computer designers in the late 1970's had to reckon with the fact that the TVs from
that era (and earlier, there were plenty of TVs as old as the 1960's in circulation in 1980) had a smaller zone they could consider "safe" from being covered up. The rule of thumb for home computer designers was they generally measured the horizontal scan line in NTSC color clocks, of which there were 227.5 across the whole ~63.5us scanline (including the roughly 1/6th of it that was used by the horizontal sync pulse, porch, and colorburst), that they could usually get away with using the center 160 without losing stuff off the sides. This is why 320 pixels across was a common horizontal resolution for TV computers; colorburst is 3.58mhz and they'd use 2x colorburst, or 7.16mhz, as their pixel clock...
(160 being roughly 2/3rds 227.5 is why I used that figure in my previous post but, sure, strictly speaking that's not an accurate ratio for the *active* part of the line. The part between the porches is around 52ms, or around 187 NTSC periods, so if you state it that way then home computer makers generally restricted themselves to using
at most about 85% of the active line.)
Of course, if you've ever actually hooked up a machine with the specs like I outlined above (85% of the active line used), like an IBM CGA card, to a 70's or 80's TV set you will probably have experienced that even that number was too ambitious and there was a good chance you'd get something cut off, or at least you'd need to hope your TV had a horizontal hold/position control. (The CGA card actually lets you adjust it on the computer end; the DOS MODE command has the "L/R" arguments to the "CO40/80" command to reprogram the CRTC to nudge the active line one way or the other relative the sync pulse.) This is why the *second* most common horizontal pixel resolution for home computers was something in the ballpark of 256 pixels. (TRS-80 color computer, TI9918/A-based systems, etc.) 256 pixels, or 128 NTSC clocks for a 7.16mhz pixel clock, is, coincidentally enough, about 2/3rds of the *active* (verses "full") line, so it works as a worse case scenario that quite a few makers of "TV machines" stuck to.
Anyway. The OP specifically mentioned the Osborne 1 as something that's getting columns cut off, so let's look at its timing because, coincidentally enough, it's pretty much the worst case scenario. (At least if it's running in its native 52 column mode, I'm not sure off the top of my head what the specs are for the 80 column cards*.) An unmodified Osborne 1 has an 8mhz pixel clock and outputs 8 dot wide characters, which makes life really easy for doing the math here; a character is one microsecond wide. It displays 52 of these characters across the horizontal which means... oh. It literally uses *100%* of the active line outside of the porches and hsync pulse. This
absolutely guarantees it's going to go into overscan on a normally adjusted consumer TV set. I think even a lot of contemporary monochrome composite monitors would have trouble with this unless they specifically have a horizontal width control that lets you get the porches beyond the bezel area.)
(* FWIW, I was able to find a pretty bad schematic of the Osborne 1 "Screen Pac", and it looks to me like 80 column mode on a so-equipped Osborne should actually be easier for a mere mortal monitor to display, because it has a 16mhz dot clock; the active area shouldn't be any wider than a Commodore 64. But since it also supports 52 and 104 columns it might still have bad positioning of the hsync pulse? As for the Executive it appears to have a 12mhz dot clock; assuming this is correct and it still has 8 pixel wide characters then this will be just as bad as the Osborne 1 in terms of *barely* fitting between the sync pulses, and therefore it's not surprising an LCD scaler expecting broadcast TV levels of overscan would have trouble with it. I'm not sure those bricks I recommended will even handle that, that's *tight*.)
