Not all is gold...

However, let's strive for a bit of balance. Using FP isn't a silver bullet that will automagically make your code better. Some FP solutions are actually tricky — and there are developers who show much glee in writing code and then asking What does this do? If you aren't careful, your code may become write–only, practically impossible to maintain... and there go Understandable, Extensible, and Reusable out of the door!

Another disadvantage: you may find it harder to find FP–savvy developers. (Quick question: how many Functional Programmer Sought job ads have you ever seen?) The vast majority of today's JS code is written in imperative, non–functional ways, and most coders are used to that way of working. For some, having to switch gears and start writing programs in a different way, may prove an unpassable barrier. 

Finally, if you try to go fully functional, you may find yourself at odds with JS, and simple tasks may become hard to do. As we said at the beginning, we'll rather opt for Sorta FP, so we won't be drastically rejecting any JS features that aren't 100% functional. We want to use FP to simplify our coding, not to make it more complex!

So, while I'll strive to show you the advantages of going functional in your code, as with any change, there will always be some difficulties. However, I'm fully convinced that you'll be able to surmount them and that your organization will develop better code by applying FP. Dare to change!