авторОпределённо следует выбрать первый ;) Потому что при реализации вторым способом Вам и правда придётся лишние элементы в вёрстку добавлять
Да, этот вариант оптимален. Оптимален по той причине, что он не порождает побочных воздействий на поведение окружающих блоков. Я так понимаю, это одна из идей методологии БЭМ.

авторИ ещё одно, если Ваши блоки могут по-разному модифицироваться (как Вы сказали, у Вас может быть множество компоновок этих блоков), то рекомендую Вам посмотреть на методологию БЭМ от яндекса.
Когда изучал компоновку картинок на странице в Яндекс и Google, впервые обратил внимание на систему классов Яндекса - ужаснулся. Если сравнить с Google - небо и земля. Теперь понятно, откуда ноги растут. Великий и ужасный БЭМ )) Хабрхабр - посмотрел - тоже придерживается этой методологии.

В идеале - да, так и нужно. Большинство проблем, которые в иных случаях приходится решать в частном порядке (как например, сабжевая задача), решаются архитектурно. Но эти самые классы...

Пожалуй, в своём проекте на БЭМ переходить не буду. Только из-за системы классов объём html-кода и css увеличится в разы, если не в десятки раз. Взять, к примеру, блок с большущим списком. Если требуется задать стили для элементов этого списка, по БЭМ придётся каждому элементу списка присваивать длиннющий класс. Сейчас я придерживаюсь "политики" минимизации html-кода и css-стилей, а в этом случае, естественно, половина селекторов опирается на теги. Там, где можно обойтись без классов, не указываю их вообще. Указываю классы для вышерасположенных (главных) блоков, а далее уже продвигаюсь по тегам.

Да, при использовании gzip и переименовании классов в продакшене, к примеру, разницу можно минимизировать, но как говорят в Яндексе, " У нас есть gzip, он хорошо все сжимает, но самое хорошее сжатие — это если не сжимать ничего "

авторИ я знаю, что li никак не будет делиться (это минимальная логическая единица), то классы будут присвоены следующим образом:
ul.list-block
li.list-block__item
a
a
img
li.list-block__item
a
a
img
li.list-block__item
a
a
img
Когда я приводил пример в большушим списком, я как раз и имел ввиду наличие длинных классов у каждого элемента списка
Ваш пример как раз и иллюстрирует это. У себя я бы сделал так:


А на уровне стилей:



Немного оффтопный вопрос: в вашей компании, как вы сказали, вы придерживаетесь БЭМ. А какой инструментарий вы используете (фреймворк, CMF или собственные наработки) ? Также интересно, какой инструментарий использует хабр (тоже придерживается БЭМ)...

автор> На текущий момент имеется 2 варианта решения (правда, не идеальные, но каждый предполагает некоторое допущение):
> 1 .Использовать плавающую обёртку для правых прямоугольных областей
> 2 .Использовать [inline-block] для красного прямоугольника

Определённо следует выбрать первый ;) Потому что при реализации вторым способом Вам и правда придётся лишние элементы в вёрстку добавлять, для размещения красных блоков в столбик. Это или br или какие-то пустые блочные элементы, которые выполнят роль br (оба варианта фиговые, ведь br вперемешку с div - не самая лучшая и понятная реализация, а пустые div выполняющие роль br - вообще семантически неверно)
Есть ещё 3 -й вариант - заключить все красные прямоугольники (области) в общий <div> с [overflow: hidden]. В этом случае для размещения красных прямоугольников (областей) в столбик достаточно им задать [float: left]. При этом они будут нормально обтекать плавающие справа зелёный и синий прямоугольники: реализация

Минус этого варианта - те красные прямоугольники, которые окажутся ниже плавающих справа синего и зелёного (и если будут достаточно длинными), под них не "нырнут", а упрутся в правую границу своего контейнера