*The short answer is:* you don't, but it saves about *1ms* of CPU time (on modern CPUs).
(Note that you should `exec` only at the end of a script, because nothing after the `exec` will get run). 


*The longer answer is:* 
`Exec` replaces the process image of the current process with the process image of the executable you exec.
That means that the moment you exec, the shell process that does the `exec`ing gets completely destroyed and replaced by the `exec`ed program.
When you don't `exec`, the shell forks itself, execs in the fork, and waits around for the child process to exit, collecting its return status, in the hope there might be additional commands to run afterwards (`fork` + `exec` is the standard procedure by which new commands get spawned).
Since there are none, the `fork` is a complete waste of time and you might as well exec directly and save on that `fork`ing time. 

For most intents and purposes, it's essentially a microoptimization based on the knowledge of how process get spawned on Unices.

______________________
**Note:** (thanks to [ilkkachu][1])
Where it makes a slight semantic difference is if the process spawning the script cares about how the maybe-exec'ed program dies.
If the mayb-exec'ed child exits normally, the exec and non-exec form are equivalent since the shell script converts the last waited-on exit status to its own exit status.
If, however, the child dies from signal `n`, then the shell would convert that to exit status `128+n`, effectively losing the signal information.
(The information is not lost if you're sure the child never regularly exits with an exit code `>128`, which is usually the case.).


 [1]: http://unix.stackexchange.com/users/170373/ilkkachu