Ок, объясняю для клоунов.

В зависимости от алгоритмики деление на нуль и рпочие переполнения могут быть проблемой логики или исходных данных. В первом случае в код пихаются assert, enforce и подобные конструкции, которые прерывают выполнение некорректной программы. Во втором случае, в зависимости от вероятности возникновения ошибки, можно проверять явно или положиться на исключения - код получается менее загромождён проверками. Ко float всё это, кстати, слабо относится - там вы получите inf, что абсоютно разумно и специфицировано стандартом.

Дальше. Да, в ваших примерах будет переполнение. Именно поэтому более современные языки имеют разнообразные средства для борьбы с этим - от BIGINT до специализированных цисловых классов. Чего вы привязались к Си, который очень беден во многих областях, когда мы говорим о Swift, скорее сравнимом с Go, Rust, C++ или D - я понятия не имею.

И, кстати, в C integer Overflow и division by zero абсолютно консистентны - и то и другое - undefined behavior. В плане реализации креш в подобных ситуациях куда лучше, чем продолжение работы с бессмысленными данными.

Разумеется, было бы лучше, если бы любыу переполнения отлавливались. Но на практике сложение/вычитание (и в меньшей мере умножение) быстры и часто используются, и проверка для каждого из них сильно влияла бы на быстродействие. Поэтому для желающих в том же GCC/Clang есть соответствующие intrinsics - и всё. Плюс на уровне ассемблера сложение/вычитание с переполнением - вполне осмысленные операции, на которых реализуется тот же BIGINT. Деление же используется редко, довольно дорого и вызывает легко отлавливаемое аппаратное прерывание.

Но никто и никогда не выставлял результат операции с переполнением в нуль по причине полной бессмылсенности.