По поводу бага выше:
Да Vue генерирует в Dev среде комментарии из template. Это поведение можно отключить вот таким образом. Тогда баг с Transition и тп пропадет

BEM-like

Будем разбирать каждый тип по очереди и начнем с BEM-like решений. Сразу оговорюсь, что тут речь не о чистом BEM, а именно о тех вариациях которые можно встретить зачастую в проектах и конкретно ДЛЯ ИЗОЛЯЦИИ (БЭМ решает и другие проблемы, но это отдельной статьи бы потребовало)

Ключевые признаки:
1) Пишем стили в <style> выбор между css/sass/postcss не важен
2) изоляция достигается оберткой стиля в BEM-like нотацию: имя компонента становится классом, далее поверх накидываются уже элементы/модификаторы и тд

Основные плюсы:
1) Нативность: для работы BEM-like почти никакого сопровождения со стороны фреймворка не требуется, работает везде
2) Простота (относительная): пишем почти как обычный CSS, но с парой правил сверху, справится любой. в блоке скриптов тоже представляется в виде обычных строк
3) Семантичность: зайдя в девтулзы найти компонент по классу легко, легко понять что именно за классы навешены на div, да и при чтении кода компонента +- понятно за что отвечает каждый тег
4) При грамотных действиях дает неплохую стандартизацию по именам классов на проекте/
5) Очень хорошо подходит для обучения новичков с точки зрения развития инженерных навыков (новички учатся быстро понимать, что классы могут иметь четкие роли, внешняя геометрия вне компонента и тд), но в реальности большинство ограничивается только базой нейминга без самой сути

Минусы:
1) Большие имена классов: то за что ругают чаще всего, что имена становятся длинными и громоздкими, есть техники уменьшающие длину классов, но они уже компромисны
2) С точки зрения изоляции, то изоляция держится на условном контракте, те если кто-то нарушит и переиспользует имя, то будет коллизия, на больших проектах имена классов раздуваются еще сильнее и перед именем блока появляется еще и "неймспейс", данная изоляция особенно течет на микрофронтендах, если не предпринять особых мер
3) Я не просто так пишу BEM-like. ибо BEM как таковой люди понимают очень по разному и каждый проект уникален в своем "БЭМ"-е. Также селекторы могут включать в себя любой хаос и не подчиняться строгой BEM-нотации
4) Относительный минус: порой людям кажется сложным поиск элемента сразу
5) Никакой защиты на уровне типизации (очепятка в имени класса обнаруживается только в рантайме)
6) Истекает из семантичности: на каждую маломальскую потребность в использовании стиля нуно придумывать отдельное имя, иногда это людям дается сложно и некоторые ощущают в этом потерю времени за зря

Нюансы:
1) Скорее всего в 99% случаев у вас будет 1 блок = 1 компонент, так как семантика понятия блока и компонента крайне близка. Действительно желание сделать блок это повод задуматься: а почему бы не вынести это в компонент (мне нравится, когда сам подход дает такие эвристики для мышления!)
2) Если вы разрабатываете библиотеку, то сохранность имен классов дает возможность расширения стилей (что в 90% зло), но иногда действительно спасает
3) Пользователи адблоков, кастомных тем/плагинов на сайтах скажут спасибо, ибо когда есть четкие классы, то их очень легко и удобно расширять и подвязываться на них

Вариации:
1) Может сочетаться со скоупами или модулями, но это во многом избыточно. Для модулей этого точно лучше избегать, так как БЭМ+модули даст крайне громоздкий и избыточный код, предпочтите подходы специфичные для модулей
2) БЭМ+atomics подход озвучивался даже в комментариях выше. Если вам нужно повесить только внешнюю геометрию или 1-2 класса, а нейминг придумать к этому нереально, то atomics прекрасно закрывает данную потребность. Тут советую больше присмотреться к unocss нежели tw из-за простоты настройки только точечных классов, а не всего подряд

Итоги:
1) В целом данный подход все еще работает, но на проектах которые предполагают большой размер, независимую разработку команд есть более современные и простые методы изоляции
2) У него есть сторонники (в том числе и я), но есть и жесткие хейтеры.
3) Подход постепенно теряет актуальность, но я все еще вижу хороший потенциал именно в обучении людей
4) Если выбираете BEM-like для своих проектов, то пожалуйста, не поленитесь и копните глубже в философию БЭМ-а (раскрыть мне все в 1 посте тут просто нереально) и подумайте еще раз надо ли оно вам

Анатомия композаблов

DISCLAIMER: сравнение натянутое и заведомо раздутое, но в нем есть и зерно истины

возможно это прозвучит дико, но композаблы не шибко отличаются от обычного ООП, только описание у них императивное вместо декларативного. И многих это действительно удивляет. Так что я решил показать это более наглядно

function useA () { // имя класса
  const b = ref() // поле класса
  const c = ref() // поле класса 2
  const sum = computed(() => b.value + c.value) //  getter (и возможно setter)
  function swap() {} // метод класса
  
  // тут может быть ваша логика конструктора
  
  // и даже деструктор доступен 
  onScopeDispose(() => { ... })

  return {
    b, // теперь b публичное поле класса (а вот С приватное)
    sum // публичный метод
  }
}

Вы можете возразить: а как же 3 столпа ООП наследование/инкапсуляция/полиморфизм.
С инкапсуляцией разобраться просто: композаблы и нужны, чтобы инкапсулировать логику в 1 месте (как сокрытие работает мы уже тоже рассмотрели)

Что насчет полиморфизма: с ним все замечательно, просто мы применяем его редко:

interface A {
  (): { // описываем параметра конструктора
    b: Ref<number>
    swap(): void // описали публичный интерфейс
  }
}
const useA1: A = () => { ... }
const useA2: A = () => { ... }

A1 и A2 реализуют один интерфейс и мы можем подменять их в зависимости от ситуации, 90% нам это не понадобится, но если сильно хочется то возможно

А где наследование то?
Ну с наследованием ситуация веселе. Сейчас такая тенденция, что наследования стараются избегать всячески предлагая вместо него использовать композицю, но многим лень, так как наследование написать на классах проще и удобнее чем композицю (особенно если хочется сохранить прежний интерфейс). С композаблами ровно обратная ситуация: мы легко можем использовать композицию, но наследование становится болезненным (чему я очень рад!)

function useA() {} // base
function useB() { // композиция ❤️
  const a = useA() // изи
  const { b, swap } = useA() // внедрение тоже легкое
  ... 
}
const useB = ({...}: {...} & Parameters<typeof useA>) => { // наследование 🙈
  const a = useA() // взяли и
  const c = ref()
  return {...a, с} // вернули
  ... 
}

Если кому интересно проверить теорию на прочность, то велком в комментарии. Но основная суть поста показать, что мы отчасти остались в тех же рамках только с переходом от декларативности к императивности, чтобы иметь большую гибкость в действиях