На сколько необходимы внешние ключи в базах данных?

1. Всегда ли необходимы внешние ключи?

Внешние ключи необходимы несколько менее, чем всегда.

2. Чем чревато отсутствие внешних ключей?

Потерей консистентности данных

3. Какие могут быть причины для отсутствия внешних ключей в этой базе?

Производительность и локи. Вот здесь отвечал на похожий вопрос в контексте постгреса, у других RDBMS примерно так же.

1. Все зависит от организации проекта, если например у Вас база данных шардированная - то внешнее ключи как бы Вы не сделаете, или например если Вы хотите избежать проверок на целостность данных при каждом изменении данных, а проводить их самостоятельно раз в сутки. В общем внешние ключи крайне желательны, но бывают ситуации когда стоит их не использовать
2. Не консистентными даными
3. В пункте 1 привел некоторые примеры

Если приложение, которое работает с этой БД само проверяет все связи на своем прикладном, более высоком чем БД уровне. - то почему бы и нет.

Проще манипулировать с таблицами, если СУБД тебе не докучает со своим контролем зависимостей.

1. Только если пихать бизнес логику в СУБД
2. Неконсистентностью данных, если её не обеспечивает уровень бизнес-логики
3. Например приложение поддерживает несколько СУБД, не все из которых умеют внешние ключи.

1000+ таблиц

Очень вероятно, что это и есть ответ.
Если вы все связи объявите как FK, модификация (вставка, изменение, удаление) одной записи в случае, когда у вас уже провалидированы все значения (а так бывает, видимо, всегда в грамотном коде), будет ощутимо замедленна этими самыми проверками на консистентность.
В противовес другим высказавшмся.
С базами я работаю 20+ лет.
10+ лет назад, когда начал работать с MySQL (он тогда никакой консистентности не умел) очень сильно удивлялся, как на таком можно работать. Но вариантов не было, работать пришлось.
Так вот.
За эти 10+ лет никогда не возникало никаких проблем, связанных с отсутствием контроля FK на стороне БД.
Впрочем, возможно, для этого таки обязательно сильно применять мозг при разработке.