Обойтись без ексепшина действительно просто, вы его ловите в трай кетч, репортаете и возвращаете не валидный респонз. Просто не полагайтесь на разные ексепшены, не пишите логику которая от них отталкиваеться.

Если вы не пишите системный код, то вам и не важно какой ексепшн упал. Вся суть ексепшна в том что это исключительная ситуацыя, если она произошла то вам и не стоит востанавливаться и пробовать чтото делать. В случае с ексепшыном вам нужно залогировать проблему и отрепортить чтоб ее можно было проанализировать. Канешно если у вас изза ошибки в коде будет Нулл референс ексепшн это чисто ошибка в коде и тут уж просто нада писать НуллСейф код, что уже канешно совсем другая проблема.

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

Нет никаких проблем с Ексепшном, это просто один из инструментов языка, плохо же кидать ексепшены самому если это не критический случай и его можна было бы решить валидацией правильном месте и т.д.
Статья же не раскрывает почему ексепшн присутствует раз он такой плохой. Любой инструмент хороший при его правильном использовании.
С таким же успехом можно сказать что Рефлекция это плохо не используйте ее, хотя это тоже инструмент для решения определенных задач.

EF прекрасно работает из коробки, и даже бредовые запросы пробует както оптимизировать. Но это также расслабляет тех кто садиться с ним работать. Люди не изучают АПИ и фреймворк, а добывают знания через интелисенс и просмотр доступных методов, абсолютно не разбираясь как они работают. В статье также было бы хорошо упомянуть тот же Апдейт/Делит данных без предварительного доставания из базы (Detached entities). Так как это ошибка которую допускают 4/5 инженеров

А чем подход использование Hi-Lo лучше Guid? поискал сам но ничего кроме «красивее» айди не нашел