Насколько я понимаю, что автоматическое распараллеливание не является killer feature на сегодняшний день. Важно скорее то, что подход ФП в будущем принципиально дает возможность развиваться в этом направлении. Для себя я понимаю, что основными достоинствами на сегодня является быстрая разработка некоторого рода ПО, которое связано с разбором сложных структур данных (парсеры/реализации протоколов/порождающее метапрграммирование). И второе достоинство - разработка более безопасных, безглючных программ за счет статической типизации.
Правда последнее достоинство важно в слабораспространенных в наших краях ИТ-направлениях как торговые роботы для бирж, медэлектроника, космос.

Теперь попробую описать какого рода объяснения мне не хватает.
Давайте сделаем экскурс в недавнее прошлое, лет на 10-15 назад. В ту славную эпоху мэйнстримом в строении учетных систем были клиент-сервреные комбайны типа dbase/clipper/foxpro/paradox.
Уже тогда мало кто напрямую писал код на си по открытию таблиц в своем формате, индексации итп. Программирование выглядело на встроенном интерпретирующем языке типа так:

USE таблица 1 с индексом 1
use таблица 2 синдексом 2
Установить фильтр на таблицу 1 по условию ......
открыли курсоры, побежали по ним, поделали операции.
закрыли индексы
закрыли таблицы

Такой подход ручного управления позволял программисту самому в каждом конкретном случае выбирать стратегию работы с объектами БД и достигать максимальной производительности. Потом во второй половине и конце 90-х на арену начали выходить SQL-сервера.
Декларативный SQL, оптимизаторы по нынешним дням не ахти вообще, дорогущие и малодоступные.
Из преимуществ явно видно только отказоустойчивость и возможность настроить безопасность на доступ.
Если поставить себя на место спорящих в то время, что лучше SQL или Fox pro, то фокспрошник мог легко запинать скл-щика, т.к. его прямое управление кодом соединений было более эффективно. Аргументы что разработка на скл проще и быстрее (после значительной перестройки и расширения сознания под концепцию обработки множеств а не записей), да и оптимизаторы станут лучше в будущем и возможно, что даже появится когда-нибудь автоматический параллелизм на те времена выглядели бы слабенько.
История показала, что SQL выигрыли и на сегодня стали действительно хороши и гибки. И планы исполнения запросов может и не самый лучшие, но достаточно хорошие для решения текущих задач.
Мне видится аналогия SQL-я тогдашнего и ФП сегодняшнего. Правда есть исключение, концепция ФП вторая по древности после фортрана, т.е. не является новой.