800 * 480 * 16bit * 30fps = 23million bytes written out to the screen per second. Don't even look at higher resolutions, it's literally exponential in bandwidth. Video takes a lot of data. The highest resolutions and framerates put the fastest network speeds to shame.

A CPU just plain can't do this. Even if you want to pretend it's one cycle per pixel the realtime constraints at higher resolutions are way out of the realm of feasible. We struggle to do CPU driven audio in realtime as-is (Audio is measured in Khz of bandwidth rather than Mhz).

You can do this at very low resolutions easily enough (again it's exponential with resolution increase) but then you have a low resolution screen.

Not dumb at all.

I worked with an ST Micro processor and small TFT display. The routine to write to the screen was to save the contents to RAM and then point a graphics renderer to that RAM. Double and triple buffering were required to avoid screen tearing (screen update with partial previous and next screen mixed.)

Is it just to be able to save all the pixel data. Intermeshing game logic processing with scanline generation is likely a bit too archaic for most projects.

I mean you can race the beam yeah, probably easier because you have two cores, but a framebuffer is easier for developers to work with.