Ну, например, если передать NULL в dest в strcpy(), то будет ошибка сегментации и работать ничего не будет.
Если наша программа такова, что dest -- при корректной работе проги -- не может быть нулевым, то некорректную работу мы увидим сразу.

А если strcpy() не упадёт, а каким-то образом скажет "ОШИБКА: у вас в dest передан NULL, копирование невозможно", то возникнет сразу пачка проблем:

1. Программа продолжит работать, хотя часть её -- копирование -- не было выполнено;
   смысла в таком продолжении нет, потому что данные уже некорректны.
   Поэтому программа упадёт где-то в другом месте, и вам придётся основательно шерстить код, чтобы найти первопричину.

   И ещё худший вариант: программа не упадёт, а испортит какие-то данные или недовыполнит какого-то действия, а вы этого не заметите;

2. Если вывод будет проводиться в stderr/stdout, то тоже проблема: многие процессы не имеют потока вывода и никто сообщения не увидит.
   У многих других объём вывода такой, что сообщения никто не заметит.

   Поэтому сценарий будет как в п.1, только уже у клиента в релизной версии (т.е. раз оно уже запускается как демон, то, скорее всего, дебаг с потоками вывода уже успешно завершён).

3. Если вывод происходит в системный лог, например, то само использование strcpy() будет тянуть за собой какой-нибудь syslog -- совершенно неадекватное усложнение при возможности просто упасть.
   И это также не исключает сценария первого пункта.

Поэтому программа при _внутренних_ ошибках -- зависящих _только_ (подчёркиваю подчёркиваниями) от устройства программы и ни от чего больше -- должна упасть сразу.
Это сэкономит вам время во время отладки.

Если у ошибок есть зависимость от внешних данных, то такие данные обязательно проверяются, ошибки с ними обрабатываются, после чего данные можно считать внутренними.