A resposta curta é: não, mas economiza cerca de 1ms de tempo de CPU (em CPUs modernas).
(Observe que você deve exec apenas no final de um script, porque nada após o exec será executado).
A resposta mais longa é:
Exec substitui a imagem do processo atual pela imagem do processo do executável que você executa.
Isso significa que, no momento em que você executa, o processo de shell que executa o exec ing é completamente destruído e substituído pelo programa exec ed.
Quando você não exec , o shell se bifurca, executa na bifurcação e espera que o processo filho saia, coletando seu status de retorno, na esperança de que possa haver comandos adicionais a serem executados posteriormente ( fork + exec é o procedimento padrão pelo qual novos comandos são gerados).
Como não há nenhum, o fork é um completo desperdício de tempo e você pode também executar diretamente e economizar nesse tempo defork.
Para muitos propósitos, é essencialmente uma micro-otimização baseada no conhecimento de como o processo é gerado no Unices.
Nota: (graças a ilkkachu )
Onde faz uma ligeira diferença semântica é se o processo que gera o script se preocupa com a morte do programa talvez-exec.
Se o filho talvez-exec'ed sair normalmente, o formulário exec e o não-exec são equivalentes, pois o shell script encaminha o último status de saída aguardado para seu próprio status de saída.
Se, no entanto, o filho morrer do sinal n , o shell o converterá para o status de saída 128+n , perdendo efetivamente as informações sinalizadas.
(As informações não serão perdidas se você tiver certeza de que a criança nunca sai regularmente com um código de saída >128 , que normalmente é o caso). Quando você executa exec, não existe mais middleman shell, e as informações de status de saída vão diretamente para o chamador do script execing (e a informação sobre se a criança saiu ou foi sinalizada é preservada, pois não há shell middleman para mesclá-la em um código de saída).
(Veja waitpid (2) para mais informações).