At the last two places I worked, I gradually led my teams from traditional OOP Ruby or Python behaviors to at least partially functional (if you'll pardon the pun).

The immediate value I was able to demonstrate was in testing. Three basic (not too scary) principles can get you a long way:

1. push mutations and side effects as far toward the edges as possible (rather than embedded in every method/procedure)

2. strive for single responsibility functions

3. prefer simple built-in data structures (primarily hashes) over custom objects... at least as much as possible in the inner layers of the system

If these steps are taken, then tests become so much simpler. Most mocking and stubbing needs evaporate, and core logic can be well tested without having to touch the database, the api server, etc. Many of the factories and fixtures go away or at least become much simpler. You get to construct the minimal data structure necessary to feed to a test without caring about all the stuff that you normally would have to populate to satisfy your ORM rules (which should be tested in their own specific tests).

Once devs see this, they often warm up quickly to functional programming. Conversely, the quickest way to get an OOPist to double down and reject any FP is to build complex chains of collection operations which build and pass anonymous functions everywhere. Those things can be done where appropriate, but they don't provide as much early bang for the buck... and they likely prevent FP from getting a foot in the door to that team.

The only real downside is that naming things is hard, and good single responsibility practices result in a lot more functions that need good names.