Аргументы вашего тимлида непрофессиональны и не подкреплены рациональной аргументацией. Ваш подход поддерживает компонентную структуру приложения. В то время как то, что предложил ваш тимлид обязывает слишком много помнить о том, как нужно писать код, увеличивает количество повторяющегося кода, в целом делает его более императивным, что плохо совместимо с идеями стоящими за Vue. В общем советую вам настоять на своём и описать почему ваш подход лучше. «я всегда так делал, мы так привыкли» — не аргумент. Ваш тимлид явно не видит абстрактную сторону и плохо понимает работу фреймворка, а может и как вы говорите, не очень-то и профессионален.
UPD.
Я исследовал комментарии тут, подумал и пришёл к дополнительным выводам, которые опишу тут:
1) Ваш подход имеет минус — он избыточен, так как содержит два слота, что делает логику неясной. Дело в том, что у вас не понятно к чему относится второй слот content. Читающий может подумать, что это контент, который выводит сам аккордеон — один раз, а не для каждого элемента. Мне такая логика особо знакома из фрейморвка WPF. Там всё так и работает, но судя по вашему примеру этот слот относится к слоту item, то есть используется не для аккордеона, а для его элементов, что неправильно, так как нарушает инкапсуляцию. Это минус вашего подхода, но он легко исправляется.
2) Минусы подхода вашего тимлида остаются теми же — многословность, императивность. Он нарушает принцип DRY.
Так вот, требуется подход, который не будет нарушать лучших практик — гибридный подход. Для начала нужно разделить понятия аккордеона и элемента аккордеона — теперь это два слабосвязанных компонента. У нас должна быть возможность менять компонент элемент аккордеона на новый, при этом не трогая сам аккордеон. Это решается очень просто. Мы просто берём ваш подход и оставляем в нём только один слот item. Этот слот будет позволять пользователю аккордеона создавать разметку по своему усмотрению. Слот content убираем за ненадобностью. В дальнейшем мы можем аккордеону добавлять ещё слоты и они будут менять его структуру, например добавлять ему заголовок или что-то ещё, но при этом никак не трогая то, как отображается внутренность его элементов (помним об инкапсуляции)! Этим должен заниматься слот items. Теперь, у нас есть возможность создать разметку его элементов. Мы можем это сделать с помощью простых HTML тегов, если у нас аккордеон в одном месте и забыть о дальнейшем (помним о принципах YAGNI и KISS). Если же у нас аккордеон в нескольких местах, причём, разметка его элементов каждый раз одинаковая, то стоит задуматься о компоненте элемента аккордеона. Его структура не важна, так что ударяться в детали я не буду. Далее мы просто создаём ещё один компонент, который будет оборачивать наш аккордеон и подставлять в его слот item соответствующий компонент элемента аккордеона (и, возможно, добавлять ещё какую-то функциональность, разметку) — типа создаём подкласс. Таким образом мы не пишем v-for каждый раз, то есть не повторяемся (помним о DRY), и имеем полный контроль над тем, что происходит в приложении. Если понадобится что-то поменять у всех, мы просто зайдём и поменяем это в нашем последнем компоненте-обёртке. Если нужно будет реализовать что-то новое, то мы создадим новую обёртку или вовсе используем наш базовый аккордеон на нужной странице (помним о YAGNI). Некоторым может показаться это избыточным. Так и есть, этим надо пользоваться с умом. Если у вас один аккордеон на всё приложение, то и думать о переиспользовании — бессмысленно. Если же компонент требуется в нескольких местах, то приведённый мною подход прекрасно подойдёт, так как основан на лучших практиках взятых из ООП.
P.S. С подходом-обёрткой мы можем даже не писать отдельные компоненты для элементов аккордеона, так как, в принципе, нам не нужны элементы аккордеона отдельно от него. Достаточно лишь создать аккордеон-потомок с нужной разметкой в слоте item.