Странное ощущение, что это троловопрос. Тем не менее.
Вы же понимаете, что методология БЭМ именования классов касается лишь постольку поскольку? Никто из тех, кто пользуется БЭМ в жизни не пишет все эти названия классов вручную, код на выходе может быть тяжеловесным, но та его часть, с которой работает разработчик - лаконичная и адекватная. Хотя, конечно, это зависит от вашего навыка проектирования и разработки. В самом Яндексе, уверяю, далеко не всегда код симпатичный и удобный.
Если вы собрались переводить ваш сайт с одного подхода на другой, вы так или иначе встанете перед дилеммой: переписывать все или переписывать не все. Другой вопрос, что двойственный подход может стоить вам куда больше полной переписки.
Исключительно в ваших силах не превращать все в выгребную кучу. Я, например, пользуюсь совершенно тривиальным подходом в верстке, который на достаточно серьезных проектах так и не скатился в тартарары.
1. Побольше частичных представлений данных. Конечно, не на каждый чих, но на каждую более-менее абстрактную часть модели.
2. На каждое частичное представление - свой css-файл.
3. Каждый элемент взаимодействия с пользователем - свой js-компонент.
Обычный todo-mvc превращается с таким подходом вот в такую структуру:
todo/
todo.view
todo.css
todo.js
todo_test.js
todoitem/
todoitem.partial
todoitem.css
todoitem.js
todoitem_test.js
Каждое представление состоит из маленького куска верстки, редко больше 50 строк. Каждый css- и js-файл - аналогично. Последний проект, который я делал по такой схеме пережил два года, примерно 10000 коммитов верстки, представлял собой мастер оплаты, веб-приложение и три админки к нему, и до сих пор адекватно функционирует и изменяется.