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

Во-вторых, всё современное девелоперское комьюнити сидит на гитхабе. На гитхабе все были, им все пользуются, он всем привычен. Поэтому вполне естественно именно его выбирать как хостинг для своего кода.

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

В четвёртых, на гитхабе есть целая куча разных мелких удобных вещей, которых нет на его аналогах. В него вкладывают много денег, его активно развивают, поэтому в нём больше всяких "фич".

Проходят оба expect. В feature тестах scenario является синонимом it из обычных тестов.
Если rspec выдал в логи, что тест прошёл, значит выполнилось всё, что в нём написано.
Чтобы убедиться в этом, попробуйте выполнить следующий код

scenario "root page" do
  visit root_path

  puts 'A'
  expect(page).to have_link("Login", href: login_path(locale: I18n.locale))
  puts 'B'
  expect(page).to have_link("Signup", href: signup_path(locale: I18n.locale))
  puts 'C'
end

Отвечу сам на свой вопрос.

Если хочется хранить массив названий в одном поле, то к "name" полю можно добавить "index_options": "docs", и количество вхождений слова перестанет влиять на релевантность.
Так же можно добавить "norms": { "enabled": false } и общая длина строки перестанет влиять на релевантность.
Но всё это костыли, которые не помогут для более сложных случаев, когда затем вам захочется сделать разные хитрые комбинации повышения/понижения релевантности для разных ситуаций.
Например, с массивом названий не выйдет сделать буст релевантности при полном совпадении одного из названий с искомой фразой.

Поэтому единственным подходящим вариантом вижу построение индекса таким образом, чтобы одно название товара "мапилось" на одну строку в индексе эластика.

Для понимания того, как считается релевантность очень помогла статья Theory Behind Relevance Scoring.

Так же для себя обнаружил, что на релевантность влияет, насколько часто встречается слово во всём индексе https://www.elastic.co/guide/en/elasticsearch/guid... И влияет оно порой очень сильно. Поэтому при реализации поиска по названиям idf фактор ранжирования стоит в обязательном порядке отключать https://stackoverflow.com/questions/33208587/elast... (работает в версии эластика начиная с 6.2)

Переименовать каталог в одной из веток, смержить уже без конфликтов, руками слить два каталога в один, закомитить.

Ноду с рельсами сравнивать нельзя вообще. Никоим образом.
Аналог ноды в руби это https://github.com/eventmachine/eventmachine - фреймворк для асинхронной работы с сокетами. Всё, что можно сделать в ноде, можно сделать и в eventmachine.
Ресурсов eventmachine будет съедать побольше ноды. Не на порядки, но в разы. Это минус, критичный лишь в очень редких ситуациях. Плюсом eventmachine будет то, что использоваться будет не яваскрипт, а руби и вся сопутствующая руби инфраструктура - тысячи библиотек(гемов) на все случаи жизни.

Вы не написали, для какой цели вы выбираете фреймворк, но могу предположить, что для какого-то вебпроекта, для 99.99% из которых ни нода, ни eventmachine не подойдут в виду своей асинхронности и низкоуровневости.

Если вам нужен фреймворк для написания веб приложения, то у rails в среде ruby/nodejs конкурентов просто нет. express.js/sinatra и другие мини фреймворки для чего-то серьёзного рассматривать не стоит, хотя если вы любите выдумывать велосипеды и всё делать руками, то можно.