Почему в крупных проектах пытаются избежать использование try catch?

Не пытаются избежать, а оставляют только для того, для чего они и предназначены: обработка ошибок. У неопытных разработчиков есть соблазн использовать try-catch как механизм многоуровневого возврата из подпрограмм даже тогда, когда никаких ошибочных ситуаций в помине нет. И именно этого не должно быть в нормальном коде.

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

Во вторых, try-catch - когда исключение выбрасывается - это медленно. Намного медленнее, чем цепочка if - return.

P.S. В Go нет try-catch - там есть отдельно явная работа с ошибками как со значениями, возвращаемыми из подпрограмм, и отдельно выбрасывание перехватываемой паники при возникновении фатальной ошибки.

P.P.S. У Янга в "Алгоритмических языках реального времени" (да, 40 лет назад и до сих пор актуальна) подробно объясняется, почему try-catch в его современном виде - зло.

Мб при написании известных тебе крупных проектов увлеклись принципом fail-fast, что конечно же неплохо на этапе разработки, но не в продакшине.

Наверное потому, что есть другие способы обработки ошибок, отработанные десятилетиями ещё в старом языке Си.
В Си до сих пор не добавили что-то типа try..catch, но ОС на нём пишут, и ничего, всё работает без больших косяков.

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

Обед