Зачем нужен FOREIGN KEY, если...

потому что любой ключ УЖЕ проиндексирован
это не играет никакой роли пока ты играешься с тренировочными базками размером в 1000 строк
но когда в базе 80M строк, объем 25PB, и она подвержена шардингу - разницу почувствуешь сразу

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

Когда мы строим реляционную базу данных мы следим за тем чтобы ее целостность не нарушалась.

Primary Key уникальным образом идентифицирует запись в таблице.
Foreign Key показывает что данные в нескольких таблицах связаны между собой.
Параметры уникальности Foreign Key и связи между разными ключами говорят нам и самому механизму базы данных о том как данные связаны между собой.

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

Из минусов:
Возникают риски нарушения целостности в отношении которых разработчики СУБД уже предусмотрели эффективные решения. Теряется смысл в части кода предусмотренного разработчаками СУБД ( решения в отношении репликации данных между разными серверами, индексирования , резервного копирования, эффективного хранения, оптимизации запросов, графического предоставления базы данных и связей в ней ).

Из плюсов:
Упрощаются процедуры при использовании СУБД. Код работающий с базой данных уже не должен в обязательном порядке предусматривать обработку ошибок нарушения целостности. Упрощается изменение связей. Не нужно более следить за последовательностью внесения данных. Отсутствие каких-либо данных можно обрабатывать на стороне пользователя базы данных. Не требуется тщательное планирование и разработка модели базы данных.

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

Foreign Key нужен для порядка в отношении внесения, удаления и изменения данных, для контроля целостности, для определения последовательности выгрузки и загрузки данных в базу данных, для графического отображения связей таблиц.

Отсутствие вторичного ключа не ограничивает вас в построении запроса объединяющего данные между разными таблицами, но может приводить к появлению сложно устраняемых ошибок, потере данных, беспорядку.
(Внесли/удалили данные только в часть связанных таблиц)

Отсутствие вторичного ключа ведет к потере информации о связи таблиц между собой и возникновения дублирующих таблиц или внесения связанных данных в неверную таблицу.
( Вместо указателя на таблицу имен в телефонном справочнике поставили указатель на таблицу фамилий)

Как и ключевое слово const позволяет избежать ошибок в программировании так и FKey позволяет избежать сложноисправляемых ошибок.