Why is there a need to render the video if live playback is flawless?
When you export a movie from a video editing software, there are, broadly speaking, three steps involved.


Rendering: reading each frame from source media and applying assigned effects to each individual clip. Compositing all tracks to form a final image. This part happens during live playback as well. However, most software will use faster and cruder methods during live playback, depending on hardware capabilities. So, the results may not be mathematically equivalent. But the average viewer may not notice the difference.
Encoding: This is the compression part. One or more rendered frames are fed to the encoder, which then performs motion estimation and other methods to identify exploitable redundancies. Using that information, the encoder generates an encoded bitstream. This part, depending on the encoder chosen, takes significant CPU time.
Writing: The encoded bitstream is then written to disk. If the frame sizes achieved in step 2 are small enough, then this constitutes a minor portion of the export process. But if not, disk I/O can add delay. This will usually be the case if step 2 is skipped and uncompressed frames are written to the file on disk.


During live playback, steps 2 and 3 are skipped. The rendered frames are stored in RAM and played from there. If the buffer overflows, earliest rendered frames are dropped, and re-rendered if requested. So, the difference in duration between live playback and render to disk is due to the better methods used in step 1 and the addition of steps 2 and 3.