Стоит ли сегодня переплачивать за сайт на ruby? Или сэкономить на php?

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

Вы рассуждаете слишком наивно: вложу в 2 раза меньше и получу то же самое. Увы, получить вы можете все что угодно от в 10 раз лучше до в 10 раз хуже, независимо от технологии.

Если речь идет об одном и том же разработчике - все равно одной технологией (PHP) он владеет лучше и возможно вам предлагают еще и оплатить свое обучение (Rails) с не прогнозируемым для вас результатом.

Если это разные разработчики, то тут нужно смотреть и сравнивать. Возможно те кто просят дешевле и делают хуже. Или, например, стандартные требования укладываются в их CMSку, а вот расширенные - ценник может вырасти в 5 раз.

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

PS: почитал тут про тормознутость ruby от коллег php-шников, кратко - это миф из давнего прошлого, современному положению дел не соответствует

На мой сугубо скромный взгляд нет в этом никакого смысла (Как разработчика на symfony2).
Почему нет: потому что у руби нет в данном случае никаких приемуществ. Как вы сказали - стоимость разработки выше, профита с точки зрения производительности - 0, руби даже больше жрет ресурсов.
Если бы был выбор между JVM-языками(java, scala) или в последнее время популярными go и erlang, ради производительности - возможно стоило бы. Но явно не тормознутый руби.

Если нужны такие инструменты как newrelic, airbrake, деплой с capistrano и прочее из экосистемы рельс.
PS: не думаю что на Symfony будет дешевле.

Осторожно! Не традиционный взгляд на вопрос.

Любой сайт работает по схеме "HTTP-запрос - HTTP-ответ".
Какая технология будет отвечать на запросы в целом не очень важно, а если для конкретных запросов это станет важно, ее можно заменить.

Нужно продумать, как будет работать приложение с т.з. бизнеса и с т.з пользователя.
Получите, условно, кучу запросов (url'ов с параметрами) и ответов (экранов, страниц), сгруппированных по функциям или как-то еще.

Затем ищите ответственных людей и даете им на проработку и реализацию те или иные части проекта.

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

Что-то может обсчитывать Руби, другой функционал может быть сделан на PHP, потому что его можно сделать за 2 дня. Что-то вообще будет отдаваться как статика.

Главное - это хороший проект (персонажи, сценарии, экраны, ТЗ) и люди на участках, будь это один человек или десять.

Мне не понятно почему в два раза дороже. Ладно бы там на 30% дороже, но в два? Сроки разработки этого проекта на Ruby даже чуть меньше, чем на PHP или приблизительно равны. Покрытие кода тестами и прочее сильно много разницы в сроках так же не дает.

Вывод, либо вы нашли разработчика на Ruby с завышеным рейтом, либо разработчика на PHP с рейтом в два раза ниже. Если второе, то стоит задаться вопросом, а хватит ли у него квалифакации? Может быть во время оценки он не учел покрытие кода интеграционными/функциональными тестами, может еще чего.

По хорошему стоимость не должна так уж сильно различаться. Рейт сильного Symfony девелопера не ниже рейта хорошего RoR девелопера. Сроки по вашему скудному описанию скорее меньше будут у RoR. Вывод, RoR должен обойтись дешевле. По возможностям Symfony больше подходит для долговременных проектов, он быстрее Ruby (на hhvm так прилично быстрее), но под RoR больше качественных готовых решений, что так же должно сократить сроки разработки.

Словом... мутно как-то. Опишите как вы получили "в 2 раза дешевле".

За rails стоит DHH и большое сообщество. Баги фиксятся быстро, новые версии улучшается производительность как и самих рельсов так и самого руби. И по бенчмаркам именно rps они все в одной категории. Про разного рода gem's вообще молчу.

На рельсах куча стартапов написано и выстрелило - работают и маштабируются всё хорошо.
twitter.com/
github.com/
www.shopify.com/
basecamp.com/?source=rail...
soundcloud.com/
www.hulu.com/

А кто пишет symfony? Не умрёт ли завтра этот фреймворк и почему именно symfony а не codeigniter какой нибудь?

Имхо я бы выбрал рельсы, хотя бы за стабильное будущее этого фреймворка. У DHH на нём бизнес завязан, написано несколько стартапов таких как - https://basecamp.com/ так, что фреймворк будет только развиваться и улучшатся.

Опытному php-программисту я бы предпочел опытного рубиста. В 90% случаев человек, работающий на руби уже попробовал php и php-фреймворки или фреймворки на других языках. И с бОльшей вероятностью он сможет довести проект до продакшена и развивать дальше.

Мне как заказчику, даже в голову бы не пришло разрабатывать подобное на ruby. Менять шило на мыло, а затем мучиться в поисках компетентных рубистов...
PS Не надо приводить нелепых сравнений - безымянных обычных заказчиков, как правило с ограниченным бюджетом, против известных компаний, с репутацией и внешними инвестициями.
Впервую очередь, для начинающихся бизнесов деньги играют первостепенную роль.

на symfony2 вы ни разу не сэкономите

На мой неквалифицированный взгляд стоимость профессионалов будет эквивалентной. Я совсем недавно познакомился с Rails, но имею продолжительный опыт с PHP. Мне Ruby очень понравился в плане наличия scaffold, что существенно ускоряет разработку. Опять же уровень вхождения в Rails достаточно высок, что говорит о том, что даже среднего уровня Rails программист будет более грамотным, нежели PHP-разработчик.
У Ruby нет проблем с производительностью, но есть проблемы с масштабированием (актуально для проектов с миллионой суточной посещаемостью), но они решаемы. Полагаю, что в ближайшую пару лет вам такое не грозит.
Если у вас действительно вышеописанный сайт, то профи-рубисты сделают вам его за неделю, т.к. там ничего для них нет особенного. При наличии верстки, естественно. Стоить это будет дороже, но чем быстрее вы сможете развивать проект, тем лучше. Опять же средства continuous integration позволят автоматизировать развертывание новых версий, тестирование и т.д. Что в итоге позволит держать разработку и тестирование на очень высоком уровне.

в вашем случаем на RoR можно не смотреть :) это точно не для вашего проекта.