Wydaje mi się, że to zależy od tego czy programiści pracują warstwami czy funkcjonalnościami.
Jeśli biznes wymaga od programistów dostarczania kolejnych funkcjonalności, jeśli taski są zdefiniowane w formie funkcjonalności, jeśli commity do repo są w postaci całych funkcjonalności, to... no, to moim zdaniem nie ma sensu się bawić w podział plików warstwami, bo będzie to podział zakłamany.
np. Ruby on Rails. Tam się dzieli projekt na katalogi, gdzie każdy katalog to inny rodzaj pliku (osobny katalog dla szabonów HTML, osobny dla kodu Ruby, który renderuje te szablony, osobny katalog na CSS, osobny katalog na JS) to efekt jest taki, że pracując nad jedną rzeczą, nad jednym komponentem, musiałem przeskakiwać po 4 czy więcej katalogach, i wszystko mi się mieszało.
Tak samo niektóre projekty w AngularJS, gdzie się dzieli na katalogi directives
, templates
, services
, styles
, co jest o tyle niefunkcjonalne, że i tak się pracuje potem na tym komponentami, a nie warstwami. Edytuje się jednocześnie templatkę HTML, CSS, dyrektywę, kontroler, więc tutaj raczej jest dużo lepiej jak masz jeden katalog z komponentem X, gdzie masz wszystko związane z komponentem X, wtedy nie musisz latać po całym projekcie, tak jak tutaj: https://scotch.io/tutorials/angularjs-best-practices-directory-structure
Jednak tu mi się wydaje, że potrzeba pewnej refleksji i nie kopiowania bezwiednie schematów (bo niestety ludzie zobaczą to w jakimś tutorialu albo ściągną w jakimś boilerplate i potem już tak zostaje, bo nie pomyślą, że można inaczej.
Z drugiej strony jeśli aplikacja ma wyraźną architekturę warstwową, to wtedy oczywiście podział katalogów na warstwy ma sens. Podział na warstwy jest fajny, jeśli faktycznie istnieje coś takiego w projekcie (w przypadku AngularJS to ciężko powiedzieć - z jednej strony serwisy są oddzielną warstwą, ale już np. zestaw dyrektywa+templatka HTML+styl CSS to dla mnie po prostu części jednego "komponentu", więc po co to dzielić sztucznie?).
Czyli w skrócie - uważam, że struktura katalogów powinna odzwierciedlać rzeczywistość/potrzeby danego projektu, a nie być kopiowaniem bezmyślnie cudzych praktyk.