Нужна ли денормализация?

Ответ от человека, который 5 лет работает с подобной системой и которая себя уже осознала.

Вы правы только от части. У вас есть две сущности - заказ и клиент. В зависимости от вашей сферы есть инициатор заказа, имя на которое сделан заказ и способ связи по заказу.

Как зовут и как связаться с тем кто вам позвонил вы никогда гарантировать не можете на самом деле. Кроме того у клиента моет быть несколько номеров телефонов и почт.

Могу посоветовать вам в случае явственного соответствия клиента и привязывать его через client_id и дублировать его ФИО в client_title (например), а так же ожидаемый контакт для связи.

Если вы будете вести только клиентскую базу то быстро упретесь в том что люди часто меняют телефоны и потом дозвониться до клиента станет невозможно. Вы убьетесь поддерживать эту информацию (вы же не ФСБ, ну)

Нужно ли, по-хорошему, в таблице заказов orders(id, client_id, ...) дублировать все поля (id, client_id, client_first_name, client_last_name, ...)? С одной стороны, так заказ фиксируется неизменным навсегда, даже в случае удаления клиента или изменения его данных. Но с другой - кошмарная избыточность, ведь в таблице заказов может быть еще другие связи 1 к 1 и в итоге полей будет миллион.

У вас не должно быть удалений клиентов. Функцию удаления достаточно реализовать через soft delete (флаг deleted_at).
Кстати а для заказа есть смысл делать другую таблицу. Historical_order_client - на тот случай если нужно запоминать факт с каким телефоном и фамилией был клиент (фамилии и телефоны меняются, а надо ли их менять в заказах - вам виднее).

Или может делать суммирующее поле типа orders(id, client_id, client_info (Иванов И. пасп. 0301 333333, тел 8999999999)?

нет. Это относится к оптимизации. Пока у вас нет жалоб на скорость работы, не заморачивайтесь. А когда будут, то введение калькулируемых полей в базу это не самый первый метод оптимизации который нужно применять.

Или может делать доп поле orders (client_id, client_data), где в client_data запихать json записи из client, что в случае чего восстановить запись.

не стоит