If it's something a sophomore with no background beyond calculus can handle, it is simple stuff. It's ridiculous that treating software engineers as though they have a bachelor's degree in STEM makes you a "LambdaBro."
Part of the reason this issue pisses me off so much is that I have a degree from one of the top CS programs in the world. I was definitely more of a theory than a systems person. And yet it still feels like a pile of unnecessary ego-stroking gibberish.
I feel comfortable saying most people who make software are less-experienced in this area than I am. When I run into this, I can at least say: "This is bullshit", and not feel the imposter syndrome of "It's just me -- I'm not smart enough for this" that I imagine most people feel.
Beyond that, functional programming is, by and large, easier than imperative programming. I love writing Scala -- It's honest about side effects, honest about concurrency, and has one of the better type checkers around. And I'm sick of seeing people try to "fence off the riffraff" by raising the barrier of entry to the Scala community.
Beyond that, functional programming is, by and large, easier than imperative programming.
It's definitely is possible to go overboard with operators, making a codebase very confusing. Case in point: the lens library. Though those are optional, and the best practice is to just use the actual word functions.
Beyond that, it's very easy to go down a rabbit hole of terminology. Javascript programmers write functors all the time, but I don't know if I've ever seen the word "functor" written in a JS context by anyone other than raganwald. They're just functions, and the fact that they return functions is damn useful.
Being pedantic: functors don't return functions, functors let you map over structures.
I totally support @jowiar on this. I have about 4 years of experience of writing in Scala and I don't think there was even one day when I needed to know monoids, functors and monads :) I have a blurry idea what monads are about but, honestly, I could have done without it.
In my work, when I make code reviews, I emphasize simplicity and readability. And I wouldn't want to see anyone of my coworkers using scalaz or a similar library. It's not true that if you don't like it you don't have to use it. If in a team of developers one person starts to use them, it's eventually going to propagate: After some time someone will have to write code accessing the code written with scalaz, then another person will have write something using that, and so on, and so on. And then it is enough that an experienced developer goes to another project and a new one takes her place (and this is not a rare situation - it's just something that happens every few months). And then the new developer looks at the code and is unable to say what is happening there without learning what all those cryptic operators and weird classes names are about.
The strength of a programming language lies not in how few times you have to push keyboard keys in order to write an application. It lies in how practical it is for a team to collaborate using it. If a team decides that the language is hard to read and hard to learn, they will search for another one. If enough teams decide that, the language dies.