1) Например, на одном домене стоят клиентский и серверный фреймворк, пусть будет Angular и Laravel, но это в принципе неважно. У каждого свой рутинг и надо следить чтобы правила в этих рутингах друг с другом не конфликтовали. У меня вот всегда была проблема понять, чей рутинг главнее и какое правило отработает первым.
Не то чтобы это прям непосильная задача, мануалов о совместном использовании фронта и бэка на одном домене хватает, но все равно мне так спится спокойнее, когда каждое приложение живет своей жизнью. Пока приложение простое и правил мало - не критично.
2) Если на проекте не фулстеки, а отдельные узкие спецы, то незачем фронту ковыряться в бэке, а бэку - во фронте. У каждого свои доступы, свой код, свой уровень ответственности.
3) В некоторых случаях к API обращается не только бэк, но и, например, мобильное приложение.
Тут идеологически правильно рассматривать API как нечто отдельное и самобытное, не валить все в кашу.
4) Меньше связанность. Вот был у вас бэк на PHP, а решили вы его переписать на Node.js, .NET или Java.
Когда бэк сделан отдельным проектом, то возни будет меньше.
Хотя на маленьких проектах или в команде фулстеков можно и не разделять.
Единого правила тут нет, все сугубо по ситуации. Обратная сторона медали в виде возни с CORS, про которую упомянули выше, тоже имеется.
