Оба направления верные,.. смешно.
Первое, если ваш проект большой или будет большим, чтобы с ним работало несколько человек, плюс это следование главному принципу - разделяй и властвуй, то максимально разделяйте бакэнд и фронтэнд, через определенную и стандартизированную api прослойку. Весь смысл - сделать разработку этих частей проекта максимально независимыми. Вас не должно волновать, на каком языке сделан бакэнд, какой фреймворк или стандарт использован, где лежат файлы и как они называются и т.п., главное - следование стандарту api их взаимодействия. Т.е. размещайте файлы в отдельных каталогах.
Главный недостаток - удобно такое делать, когда проект уже готов и в нем появляются только редкие допиливания, т.е. стандарт api уже завершен и серьезно (в структурном плане а не конечные его функциональные листья) изменяться уже не будет.
Главное достоинство - вы можете переписывать свой проект (например как один из способов избавиться от технического долга) независимо, т.е отдельно бакэнд, отдельно фронтэнд и в идеале отдельно верстка.
Второе, если ваш проект никогда не выйдет за стадию начинающего, если вам проще плодить технический долг но экономить троекратно на времени разработки, если вы один все делаете и больше никого в проект не ждете, размещайте все рядом, или даже попарно в одном файле, благо php это позволяет (плохая кстати практика, правда если у вас есть промежуточная прослойка, собирающая проект из ваших файлов в эффективный комок статики и кода, то оправдана) - то делайте так. Структурно, это очень удобно работать с логически связными файлами вместе, сразу видно где что не доделано, удобно в интерфейсе в один клик переходить мед уровнями разработки и т.п.
