Не соглашусь с ответом Reaching the Heavens. Хорошая производительность и перераспределение памяти не являются атрибутами функционального программирования и даже не является атрибутам вообще какой-либо парадигмы программирования. Хорошая производительность и перераспределение памяти могут быть у конкретного языка, платформы и среды выполнения. Я уверен, что если я сяду писать функциональный язык программирования, никто не сможет написать на нём хороший, производительный и эффективно расходующий память код)
Основное преимущество функционального программирования, на мой взгляд, это отказ от разделяемого состояния, которое является главным источником проблем в крупных многопоточных системах. И чем крупнее и многопоточнее системы, тем проблемнее, ведь копий об организацию многопоточного доступа к объектам в памяти миллионы было сломано уже очень давно, десять лет назад, а то и больше. Масштабы и аппетиты в enterprise с тех пор сильно возросли, а ставший классическим ООП-подход никаких масштабируемых решений проблем с конкурентностью не предложил. Вот и вспомнили запылившуюся в восьмидесятых любимую математиками-гиками игрушку и поняли, что ей сейчас действительно и время, и место.
ФП как раз пришлось в тему, когда последние инженеры перестали считать, что 640 килобайт должно хватать каждому; когда качественная и поддерживаемая реализация бизнес-требований стала дороже, чем покупка бесконечных виртуалок в Amazon'е; когда высокоуровневые, прожорливые до памяти, но чертовски удобные и безопасные языки упёрлись в потолок парадигмы, по которой они реализованы. ФП хорошо своими ограничениями, ведь именно свобода в абстрагировании и инженерии в долгосрочной перспективе приводит ООП-код к тому, что он становится страшным, никому не понятным, токсичным монстром. ФП не то, что решает проблемы многопоточных систем, он не позволяет программистам их создавать.
Тут уместнее порассуждать о том, почему ФП до сих пор не стал доминирующей концепцией, а всё ещё считается некой "альтернативой". Проблема его по сути та же, что и у ООП - оно не позволяет сосредоточиться на бизнесе, а требует внимания само по себе. Сейчас, когда так актуален DDD, когда IT пронизывает всех и заказчики уже сами тебе рассказывают, у каких сервисов есть API, когда программисты вот-вот научились общаться с аналитиками, менеджерами, клиентами на одном языке, абстрагируясь от технических нюансов, ФП снова даёт нам какие-то сложные, оторванные от реального мира математические концепции, под которые если и можно подогнать бизнес-требования, то никто не станет. ФП - не инженерная концепция, а математическая, и поэтому я считаю лучшим решением на данный момент брать лучшее из двух миров: абстракцию и модульность из ООП и immutable/side-effect free дизайн из ФП.
Самое основное: более хорошая производительность и перераспределение памяти, лёгкость изучения с нуля, упорядоченность библиотек, в чём ООП всё таки отстаёт. С другой стороны, функциональное программирование сильно отпугивает вообще буквально всех, поэтому перспективы у него достаточно туманные. (хоть и всякие ТК можно развить, а за тем и будущее?)