VueJS: минусы компонентной структуры?
Несколько общих соображений:
1. Если проект развивается, и вы не переписываете что-то уже готовое, то на начальном этапе нет смысла сильно заморачиваться со структурой. Просто делайте своевременно рефакторинг и приводите структуру к более удобному виду по мере развития.
2. По опыту более удобно все-таки иметь более плоскую структуру папок, иначе со временем по ним очень тяжело делать навигацию.
3. В вашем варианте вы получите много одинаковых файлов index и menu например. Как правило в редакторе открыта куча файлов, для названия остается мало места и у вас будет множество вкладок index.vue в итоге. Т.е. лучше делать название файла более информативным типа:
header\
  HeaderLayout.vue (или Header.vue или HeaderBase.vue ) - базовый компонент, который так или иначе использует другие.
  HeaderMenu.vue
  HeaderTitle.vue
  и т.д.
Лично я обычно имя компонента делаю равным имени файла.
4. Если не смотрели, стоит прочитать style guide по vue: https://vuejs.org/v2/style-guide/
5. Тесно связанные файлы и папки лучше держать ближе к друг другу для упрощения поиска.
6. Для базовых компонентов, чтобы отличать их от компонентов фреймворка например, можете сделать свой префикс типа app-button, app-selector и т.д.
Все зависит от требований к структуре. В зависимости от них определяется ключевой параметр относительно которого проектируется структура. Ваша структура ориентирована на включение, недостатком таковой является путаница в случаях когда компоненты/модули пересекаются в дереве, к примеру когда 2 ветки используют один и тот же компонент. То есть у этой структуры есть ограничения расширяемости. Я больше предпочитаю структуру ориентированную на зоны ответственности. То есть это горизонтальная структура. Ее основной недостаток - полотно файлов и папок в обозревателе, так что без вкраплений иерархических структур папок так же не обойтись(стоит 100 раз обдумать). С другой стороны она позволяет легко ориентироваться в функциональных модулях системы и группировать внутри папки с модулем ее функционал(не выходит за рамки задачи модуля, тесно связан между собой).