Before one can say whether video games "draw" the display every frame, it's first necessary to define what is meant by "draw". There are certainly many video games certainly do not all draw every frame by assembling a bitmap from scratch; indeed, many gaming platforms never assemble full bitmaps at all.
There are a few approaches video games can take to generating a display. A very small number have the CPU turn the electron beam on and off or for every pixel or, for vector-scan games, set the XY coordinate of every dot to be plotted. Most games that do this do so largely for the purpose of demonstrating that the CPU is fast enough. More commonly games will have hardware which, in the absence of CPU involvement, would output some pattern of pixels or vectors to the display repeatedly. This pattern may be produced by reading data sequentially from a region of memory and interpreting each bit or group of bits as a pixel color (this is called a bit-map display). In some cases, hardware may read a byte of memory for each 8x8, 16x16, or other size region of the display and then use that byte to select a range of memory to read for pixel data (this is often called a character-map display). Some hardware platforms can overlay multiple bitmap displays with configurable positions. These are referred to as sprites.
Some platforms do not allow the display pattern to be changed while it is being sent to the screen, but instead require that all updates occur after the beam has finished drawing one frame but before it has started drawing the next. On such platforms, everything that is going to appear on a frame needs to be loaded into the display hardware before the start of that frame, and the display will be limited to showing a pattern that can be set up all at once. If the CPU were to stop running while the frame is being shown, that same frame would keep being shown indefinitely. Other platforms do allow the pattern to be changed or reconfigured while it is being drawn to the screen. This makes it possible to show a screen which is much more complicated than the video circuitry could handle by itself. This may make it possible for a hardware platform which has eight sprites to show a larger number of movable objects by setting the positions of the top eight objects on the screen, waiting for the beam has reached a point somewhere between the bottom of the first object and the top of the ninth, setting the position of the ninth object, waiting for the beam to get between the bottom of the second object and top of the tenth (if it isn't already there), setting the position of the tenth object, etc. Note that this approach would require CPU involvement during every generated frame of video, even if none of the objects visibly move, but the CPU would not be involved with "drawing" each object.
Most personal computer games use hardware configured to draw a single bitmap screen, and then draw onto that screen anything that needs to be different from what's already there. Sometimes it may be easier to draw things without regard for whether it is actually necessary in a particular case, but if code can easily tell that there's no reason for part of the screen to change, performance may be improved by skipping that part. Today's platforms are often fast enough that they could draw the entire screen many times over during the course of a frame, but historically that was not the case. The fastest possible code to write all the pixels on the Apple II computer's high resolution screen, for example, would take more than two frames, and the fastest possible code to copy all of the pixels on the Apple II computer's high resolution screen from another buffer would take twice that. Getting good performance required that games only update things that were actually changing, and that is what good games generally did.