Элемент блока не обязательно вложен в блок.
На уровне DOM-дерева элемент может содержать в себе все, что угодно — и другие блоки, и другие элементы.

<div class="first-block__element"></div>
<div class="first-block"></div>
<div class="second-block">
      <div class="second-block__first-element">
            <div class="second-block__second-element"></div>
            <div class="some-another-block"></div>
      </div>
</div>

Автор комментария имел в виду, что элементы не могут содержать в себе элементов на семантическом уровне.

В БЭМе?
Названия блоков придуманы автором статьи, при чем здесь методология?

Я думаю, у человека просто привычка. Взгляните на современные open-source библиотеки Яндекса, выполненные по БЭМ — там сложно найти вообще какие бы то ни было префиксы.

Вы берете чужие игры с открытым исходным кодом, изменяете интерфейс и продаёте, не сохраняя при этом открытость кода и не оставляя ссылку на оригинал?

Это dev-сервер, который нужен только разработчику. В случае ошибки сборки он даже не начнет работу.

Зачем не-верстальщику разбираться в этом?
Ну и никто руками это не пишет, в исходниках все читабельнее некуда.

Вообще я не поддерживаю политику зависимости блоков друг друга.

Блоки зависят друг от друга, в любом случае. Простейший пример — блок формы зависит от блоков инпутов.
Кроме того, блоки зависят от своих элементов. Бывает, что один блок с разными модификаторами зависит от разного набора элементов.

Порядок сборки блоков можно регулировать пока только в файлах application.css, application.js, где ведется список всех компилируемых блоков.

Опасный подход. Ручное разруливание зависимостей ведет ошибкам. Хотя бы что-нибудь вроде require.js используйте, что ли. Но, видите — require он все-таки про js. а deps.js — про любые технологии.

Я имею в виду, что, используя bem-tools и deps.js,. я могу указать, что блок А зависит от блока Б, а блок Б от блока С. Потом подключить к странице блок А — и получить собранные в правильном порядке скрипты и стили всех трех блоков.

Доопределение блоков — не только css, но и логики, и шаблонов — мне кажется, нужно обязательно.
Про ассеты не пропустил, в части про ассеты нет ничего про разруливание зависимостей между блоками. Или это я что-то не так понял?

Одна директория с блоками для всех проектов на Ruby on Rails.

Уверены?
Блоки удобнее разделять на библиотеки. Библиотеки — подключать к проектам. На уровне проекта переопределять блоки.
Плохо представляю, как тут обойтись одной директорией.

bem-tools не подходит по вполне понятным причинам

Я не совсем понимаю, по каким.Только из-за того, что инструмент написан не на руби, вы решили писать свою реализацию? Или есть какие-то объективно веские причины?

Про deps.js можно забыть.

Забыть про автоматическое разруливание зависимостей и разгребать их руками?

Чтобы его использовать можно было бы подключить в рельсы V8 и компилировать шаблоны. Но тогда от рельс мало чего остается и это далеко не Ruby way.

Рельсы — это разве только шаблоны?

Хотя мне всё равно не понятно, откуда берутся попытки залезть на github.com.

Судя по статье, используется bem-bl, а репозиторий этой библиотеки — на github.com.

Простите, что вмешиваюсь.
Мне кажется, комментарии вроде «вот бы еще эта штука умела делать то или это» неадекватны формату топика. Этот топик — попытка научить что-то делать, а не предоставить продукт.

То есть этот топик так позиционируется. А на самом деле это реклама 4tree. Ну и да, согласиться, что это «потрясающий тутор, написанный грамотным языком, просто, понятно и с крутыми примерами / практиками» я не могу, конечно.

Мне кажется, новичкам лучше не показывать плохой код. Вообще никому лучше не показывать плохой код.
Лучше закешировать в переменную, как указали выше, а для новичков оставить внятный комментарий, что это и зачем.

Настраивается же.
Но в любом случае, сравнивать jshint/jslint с PVS-Studio несерьезно, конечно.

После продуктов JetBrains назвать это IDE язык не поворачивается. Текстовый редактор — да, наверное, даже не самый плохой.

Да, существуют.
Шаблонизатор зачастую используется, как «царапки» для верстальщика, чтобы он ничего не мог сделать, кроме как данные каким-то образом вывести.
В таких проектах есть большая команда профессиональных верстальщиков, они умеют только верстать, но делают это отлично.
Все, что они знают — это HTML, CSS и синтаксис шаблонизатора. (Возможно, нескольких шаблонизаторов и базовые знания какого-нибудь PHP или JS) И это не новички, которые до поры до времени делают простые задачи, в том числе пишут шаблоны. Это профессионалы, которые верстают годами и не заинтересованы в росте в программистов, более того, они могут считать, что быть верстальщиком и собираться стать программистом — нонсенс.

Есть вот такой баг.

Если комментарий адресован мне, то да, я это имел в виду, ккогда писал про то, что код хочется «просто набрать в консоли».

IDE от JetBrains — это прекрасно. Если же говорить именно о node.js, то все еще очень далеко от идеала. Например, debugger — очень слабый. Чтобы выполнить код, нужно открывать дополнительное окно «evaluate», вместо того, чтобы просто набрать в консоли. В списке переменных текущего контекста нет this и arguments — а их стоит показывать, если this != global и arguments.length !=0. В watch нельзя добавить переменные, не объявленные в текущем контексте. При наведении на переменную в коде всплывает окошко с описанием, что в переменной, но если в переменной объект — нельзя посмотреть его свойства прямо в этом окне. Хм, кажется, так долго можно продолжать)