It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time.
For a PC, you'll most likely have USB latency, double-buffering, latency between the graphics card and the screen, latency due to picture processing in the screen. All that is additional to the 1ms that the pixels need to switch color after the instruction to do so has been received.
In addition to these excellent points, the "1 ms" pixel response time is measured grey to grey i.e. favourable to the display and not real-world. The bigger problem with advertised pixel response times is there is no industry standard measurement procedure (which grey to which grey?, is hdmi processing latency counted?), so pixel response times are vague, mostly useless marketing.
You don't have to believe these claims you know. And you need to add up all the latencies of all the components in the chain, from your keyboard and mouse to DirectX or whatever it is...
It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer.
You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/palette settings. You could change where the sprite is halfway across the scanline, and it might immediately, in the middle of drawing a scanline, output a different color. There was no delays anywhere in the system, only the propagation delay of electricity in wires and transistors. The various HW registers that controlled what and where the sprites were were connected via a small pile of non-clocked digital logic gates to a DAC to the analog output pins of the graphics chip, which was connected to the electron guns directly if you used component video or via a simple, no-latency analog circuit if you had composite video.
These days, you program the graphics card to draw what you want it to draw. Once you've programmed everything for it to draw, it draws that into the backbuffer. Once the current frame has been sent to the display, the backbuffer is swapped with the frontbuffer. When the next frame begin is sent to the display, your changes finally go out across the wire. Depending on the display (see especially motion adapting TV screens) there might be more delay. Then whatever changes you make are finally displayed on the screen.
It's kinda weird. Old video game consoles (up until the SNES and Genesis) had extremely low latency. And that's been gone for 25 years. Not only is it gone, but it will likely be gone forever- we don't even make the technology anymore to show the new generation what it was like. On the one hand, the new technology is "better"; there's no way to do today's advanced graphics without a deep drawing pipeline that outputs to a frame buffer. But it's also somehow worse. We can make it less bad with technology like 144Hz and Freesync, but the old era is gone.
I started on the Apple II and i'ts been downhill since then. If I remember correctly the Apple II has one of the smallest latency between touching a key and seeing the result on the screen.
While this is true of LCDs, OLEDs have basically no draw latency, so conceivably they could directly update as the frame buffer was populating like a CRT if the gpu driver and OLED driver allowed it. This would still have tearing though for a modern game, so it is likely that it would need to buffer and draw entire frames at a time, which could still give you only 1 frame of latency. Most of the older games were not updating the positional information of sprites between frames (just using scanlines for raster effects) so there was already 1 frame of latency on input updates.
The N64 had a unified memory architecture, so the frame buffer was just a region of memory within the unified system RAM that was drawn to. The Z buffer was the same way. (assuming the programmer chose to enable to the Z buffer) It was still a frame buffer though.
The scan speed is exactly the same for all screens when driven by the same timings (resolution, blanking, refresh rate), so there is no difference there. Most digital screens have some processing lag, for gaming screens usually 1-4 ms. This doesn't exist in a CRT. LC panels have a pixel response time, somewhere around 1-40 ms depending on the color change, drive mode and panel type ("1 ms" is always a grey-to-grey transition and generally with overdrive). CRT phosphor lights up practically instantly when hit by the electron beam.
So for a given set of timings, you'd always expect the CRT to be faster, because it represents the absolute minimum time-of-flight delay, assuming it is driven by a direct RAMDAC and not by a conversion box buffering an entire frame or significant portions.
Also, you can "move" electron beams at extremely high speeds. Even in a magnetic deflection CRT like the GDM-FW900 the electron beam can move at more than 80 km/s[1]. In some electrostatic deflection systems the speed of light is exceeded: they can draw a dot moving across the face of the CRT that moves at a higher speed than c. This is possible because "the beam" is a fictional object.
[1] 2304 dots across 482 mm with a pixel clock of around 384 MHz means these 2304 dots are covered in about 6 µs; 482 mm/6 µs = 80.3 km/s.
The NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.
You misunderstand the video. A LCD controller must buffer at least one line, because the LCD matrix is updated line for line, all columns in parallel -- it's a matrix, much like a RAM matrix. However, the video just shows how the LCD is scanned out, it doesn't say anything about the buffering of the controller. A lot of non-gaming LCDs, and virtually all older non-gaming LCDs, buffer an entire frame, even if they are driven in their native mode.
You just can't get that responsiveness anymore.