Distinctly not looking for arguments like “Scala/Rust/etc. have a functional flavor, and companies use them, therefore you should learn FP”

The most successful arguments in favor of FP that I've encountered came from Rich Hickey and Joe Armstrong talks, describing how they arrived at the philosophies that support the design of Clojure and Erlang.

Simple Made Easy, for instance, seems to be the gateway drug that gets a lot of people hooked on FP. So an answer to your question might be found in there.

When it comes to concepts, skills, real world examples.. that's actually the point where I fall off the FP train. I've found it's easier to justify the benefits of writing all your code in C, getting a lot more intimate with registers and memory allocation and nurturing the skill of mechanical sympathy, doing any advanced data manipulation yourself — rather than leaving all that to the compiler and benefitting from a language that lets you explicitly label your algebraic data types (etc).

Being aware of category theory and abstract algebra... being able to know when you need to use an abelian group (eg: for perf reasons) — that's valuable. But once you have that theoretical knowledge, you can leverage it in whatever language you want.

People typically seem to learn that theory at the same time they learn Haskell, so I think the benefits of the former are conferred upon the latter (not undeservedly, since Haskell does allow you to be a lot more explicit about your algebra than most languages). But there's nothing stopping you from taking "FP, The Good Parts" and doing it in whatever language/paradigm you want.

So to answer your question, I'd say the concepts to know are things like.. associativity, commutativity, set theory, a tiny bit of group theory... and things like the joy (and pain) of a pure function, the pain (and joy) of a side effect, etc. The motivating examples are things like.. the difficulty of unit testing stateful code vs pure code, the ease (and joy) of finding analogies between things like sets, and vectors, and maps, and functions (in the math sense), and functions (in the colloquial C/Java sense) when you know about concepts like fixed points, functors, the hyperoperation sequence, etc. There's nothing really in there that is conceptually under the umbrella of FP — it's just math, and FP just makes good use of math — but a good education in FP should probably teach you all of that math stuff.

Category theory and FP is full of obscure jargon which confers great solemnity on people, but from a readability point of view languages like Elm fall very short. They are very hard to understand, and Haskell is also terrible. In the commercial world if you can't transfer the code easily from one team member to another, it will have very poor acceptance. Look at the problems Boeing is having, trying to get their MCAS software accepted by the FAA and airlines. They are losing over a million dollars a day because other people can't verify a fairly simple program is accurate. The airplane has a constantly changing state, and the finite state machine they have programmed has to respond sensibly. Having software be robust is very important, and although the concept of pure functions is a fun one, and allows for easy composition, frankly very little of my code one has to write is composable. I don't take the output of a function and feed it to a long chain of functions very often. So the mathematical wonders of composition are just not that usable a great deal of the time. Most of the code in a graphical interactive product is devoted to handling input, and drawing things, none of which are heavily nested. Lots of graphical constraints, and heuristics for sizing and placement.