Interlacing works basically by adjusting the start time of a new field (half-frame) forward or back by half a scanline in relation to the previous one. Thus either the first line is complete and the last one finishes early (after starting normally), or the first one starts late (but ends at the normal time) and the last one is complete. Literally, when it's stated as "312.5 lines per field", that's the honest truth, not an averaging of a 312 and a 313 whole-line pair. You could see it as a single extra-tall frame of 625 lines where an extra Vsync pulse is issued EXACTLY halfway down the screen.
As the main horizontal AND vertical scan circuitry is continually running, at a steady pace, and each one always resets to the same distance up or across the screen regardless of what the other does (hence the 2D rolling effects with a desynched signal), there's nothing to say a Vsync can't happen at any arbitrary point along a horizontal line... and each line is actually very slightly diagonal - its position up/down the screen at its start point is essentially the same as the end of the previous one, plus a tiny displacement caused by the flyback time (ditto the vertical, if you could make the very last and very first lines visible between an "odd" and "even" field, the last line of the odd field wouldn't be quite 1/2 length when it finished, and the first line of the even field would start a little after halfway, with a very steep, dim (as it's more spread out) line connecting those two points across the entire height of the display, with the signal structure and circuitry designed to make it all even out. And, at least for computer monitors, a minuscule little twist engineered into the orientation of the electron gun (and, for colour, dot/aperture mask) assembly, and a slowly shifting bias to the horizontal deflection, to make the lines actually horizontal but with a much steeper descent on each flyback... (without the shifting bias they would have obvious trapezoidal edges because the Vscan centreline is no longer fully vertical)
The net effect being that the second line of an even field is displaced upwards by half a field-line height compared to the second line of an odd field, because it starts half a line-time earlier compared to the start of the vertical sweep. And so is every other "even" line vs its matching "odd" line. (The first, half-length one starts at the same height as its counterpart, but it's already halfway along, so the odd line has already descended by half its full sweep height).
Naturally, with a non-interlaced scan, connected to a simplistic old school single-frequency CRT that ALWAYS deflects its beams at the same rate (ALWAYS!), and whose only sop to a not-quite-correct input scan rate is to reset the deflection to the "zero" (minus preset calibration bias) position in time with the appropriate H or Vsync pulses (so long as they're not so fast that the flyback circuitry hasn't fully charged, nor so slow that the beam has deflected way off the screen and the circuits are overcharged... by which point a safety trap circuit should've kicked in and issued an automatic unsynched flyback anyway), each field will exactly overlay its predecessor, at twice the normal rate, but with nothing at all displaying on the lines that would be taken by the other field. Hence, scanlines. The basic TV / 15khz monitor is a pretty unintelligent beast, it just looks for those particular pulses and resets when they come in, not holding a great deal of information in state re: scanrate, line count, what the current field is, etc. Most of the cleverness, including the 4-field colour sync cycle for broadcast images, is inherent to the signal instead and dealt with by what were originally very complicated room-filling machinery at the studios.
But, there are differences between the existing standards, and here I think is the root of why NTSC computer/console displays at 240p have obvious scanlining, whereas PAL ones generally do not. Or did not, should I say?
1/ Higher inherent resolution, and often smaller screens. The lines are crammed closer together by about 20%, and may themselves be smaller, which leads to a bit of physical "Kell" smearing (which for broadcast material lowers the apparent resolution by anything upto 30%) that's worse for smaller sets than large ones because the actual overshine radius stays about the same... thus is proportionally wider.
If you're sitting a few feet away, a small 12 or 14 inch screen with a not particularly fine-grained mask (especially if it's a dot/cluster shadowmask rather than aperture type) simply isn't able to render each line with enough clarity at your eye for you to easily pick up on any discontinuity.
2/ PAL colour encoding, vs NTSC. This isn't relevant to RGB connections, true, but some of the cheaper ways to implement the decoding may still have been permanently active regardless of input method (certainly, when our ST's CM8833 was run in 60hz by a game that could do the switch, it seemed a lot more "liney" than might have been expected, and far moreso than at 50hz - the vertical height was increased automatically too, meaning it had at least enough intelligence to detect between the two modes, and therefore potentially change other display circuitry settings, because a truly "dumb" monitor would have shown a 320x200 image at the same size just with smaller vertical borders, and probably displaced upwards somewhat).
The main method I'm thinking of here is the rock-bottom "PAL-S" mode, which relied on simple visual smearing and interpolation to produce the final colour from the two opposite-phase components that would otherwise both be the wrong colour... essentially dealing with the line-by-line colour dithering by blurring them together, partly physically at the screen, partly in the eye, and partly in a temporal (alternate flash) fashion. This is what's behind the faint "green and purple" and "red and blue" stripes seen in the closeups. Obviously, the way this works is by making each line excessively tall (either just defocussing the gun a little and accepting the blurring effect this would also have on the horizontal resolution, or increasing the amplitude of any installed "spot wobble" circuit which oscillates the vertical deflection voltage very slightly at extra-high speed (10+mhz), increasing the apparent height (and edge-softness), and slightly reducing the brightness, of each line as the gun aim jitters up and down a bit several times within one spot width's worth of sweep. Normally this would make the otherwise quite starkly different and contrasting interlaced scanlines overlap just enough to reduce the stripes to more of a faint wavering gradient pattern instead ("hanover bars"), mainly only really discernible with artificially strongly-saturated colours, and greyshades on signals with a lot of phase error, disappearing into homogeneity with a cleaner or less saturated signal. For a non-interlaced computer, it smears each actually-scanned line far enough into the unscanned region that adjoining field lines should overlap slightly (thus reinforcing each other in the very middle of the unscanned area)... and as they're double-scanned, therefore being made twice as bright as they otherwise might have been, those more dimly lit overlap areas are also considerably above black, and there's the effects of stronger phosphor overshine to consider as well.
(that said, I am a little confused at seeing those vertically-displaced hanover bars - what SHOULD happen is that each opposite-colour line is directly overlaid on top of the previous one, and so you'd instead see a very rapid shimmer effect, alternating temporally but fairly stable in the spatial dimension... and in fact if it's a baseband or a reasonably clean RF signal with no skew or other phase issues, and the monitor picks up the colourburst properly, the phase reversal should happen the same on both sides, and it would then scan the same colour for each line anyway. Colour mixing isn't an essential part of getting an accurate colour image out of a PAL set - it's merely one of its robust error-rejection features where an image tends more towards monochrome as its colour components are symmetrically displaced (NTSC lines in one direction, PAL in the other) by phase errors picked up along the transmission path, but the hue remains relatively stable. Hence no hue control on most PAL sets. So here it's maybe more likely that one or more of the colour guns isn't aimed entirely straight compared to the others? EG there might be a slight vertical mismatch between red and blue, but a bigger one between both of them and green, almost as much as a half line in fact; so in the not-quite-white background image (paper 7, bright 0), the magenta/green contrast is most obvious, as the "dark" lines are being lit mainly by the green gun, and the "light" ones by a reasonable overlap of the red and blue, with their own displacement masked by the overall brightness, and the further interference with each to produce cyan and dim yellow. On the magenta border, where the green gun doesn't fire at all, the displacement of the red and blue guns becomes more obvious, as now each not only overlap each other to make a magenta combination for the "lit" lines, but also claim a portion of the "unlit" line for themselves, forming a red and a blue stripe outline alongside; one suspects yellow would then give an impression more like white, and cyan more like magenta, with each of the three primaries having a more clearly scanlined appearance, much like the pixels on an overly coarse LCD.)
For NTSC, no such scheme is applied, as the only smoothing-out technique applied to the colour is to shift the clock a little each line and each field, which counters some of the dot-pattern effects but doesn't do anything for phase errors as it's always in the same direction and orientation. So every line is an NTSC line, there's no need to smear the colours between them, and there's fewer lines anyway so the spot wobble / gun focus is made as tight as can be got away with whilst still producing a smooth, uniform picture in full interlace. Thus when you switch into progressive, the most help you get is overshine from the inherently brighter scanlines.
A different PAL scheme is that of the acoustic (later, digital) delay line where the colour info from one field is stored directly into the start of the line, whilst simultaneously being summed with what comes out the end of it after exactly one field time's, plus or minus half a line (IE either 312.0 or 313.0 lines, because it has to be reused with a slight displacement... maybe alternating with two very slightly different lines, even), and that used as the actual colour information for the current line. Aka PAL-D.
(obviously, this gives you some lines, especially halflines, where the delay doesn't work right, and you get an output line with wildly incorrect chroma... this shouldn't matter though, given that the halfline is DEEP in the blanking area, and any artefacting output would be well into overscan and not seen.)
Thing is, that doesn't store the luminance information in any way. ONLY the colour. And it still doesn't do anything for further filling in the black areas anyway, as the beam still scans over the same half-frame / single-field positions, just with more accurate, less changeable/shimmery colour now.
So, erm ...
My money is on either the sets somehow automatically switching field start position anyway in the absence of a fully accurate sync signal (counting lines and ignoring the vsync after the first few fields have got it locked in), Sinclair telling a pack of lies and the composite/RF output actually being interlaced even if the RGB isn't (it might even just be an unavoidable feature of the composite encoder / RF modulator that it adds interlaced-spec timing/sync to the incoming image data even if that means actually outputting an alternating string of 311.5/312.5 or 312.5/313.5 line frames in response to a 312 or 313 progressive input), or it simply being a misfeature of badly aligned electron guns, defocussed spots, overenthusiastic spot wobble and phosphors with leaky photon wells.
What you really need to do is either get an oscilloscope on there, or use a really high framerate slowmo camera (like, at least 100fps...) with good enough resolution that when you single-step the recording with decent zoom on the screen, it shows you clearly whether the image scans over the same place on every single field and it's down to a combination of other factors, or whether it really does interlace despite claiming not to. And do that with a variety of screens, and a couple of rival machines.