When I decided to click on the title, I imagined words of wisdom on really when FP is suitable (or not suitable). Instead, I found some talk about functions being in order or in not so good order...

Well. FP is much more than processing data in map-reduce fashion. For example, it is much easier to formally verify functional programs and usually FP also means better type safety. It's also about leveraging mathematical theories (category theory is one brilliant example), so the difference (Wadler told it - here ( https://medium.com/@Max_Goldstein/every-language-is-invented-c67d733ec01d ) medium article, treating it) is to work with your own inventions vs discovered eternal truths.

This is especially visible in Haskell and it's likes. If you found that your structure is, let say, a monoid, there is a library for it and pieces just fall into place. In Idris (another FP language, reminiscent of Haskell) you can even generate function implementation given function type (it's called TDD there, where T is for Type, not Test).

Another area for FP is building compilers. Here Ocaml is probably the best choice, though Scheme and Haskell are not that far behind. And compiler also means you can make your DSL (domain-specific language), which can make the system you build much more flexible.

There probably some downsides in FP. Perhaps, the biggest one is that it's still not mainstream and realtevely less software developers are capable to do it.

The rest I hoped to read from your article. Maybe, one of the next ones?