At the code snippet level, 40 lines of redundant code may well be easier to read than 2 lines of, say, function composition. And 100 lines of familiar redundancy will feel much easier to work with than a small amount of strange-looking symbolic compactness. But anyone who believes that a million lines of redundant code are easier to work with than ten thousand lines of compact code (I'm making these numbers up) is deeply deluded. This is how software projects end up with hundreds of programmers frozen in concrete. (People think of code as a commodity, as if it comes in sheet rolls that you cut enough of until your project is complete. This is a fundamental mistake.)
The root issue is that the number of programmers content to crank out redunant code is at least an order of magnitude (maybe two) greater than the number who are capable of working effectively with abstraction.
If that's correct, then there's a market opportunity in it. A small startup with programmers who do know how to program in more powerful languages (FP or otherwise) ought to be able to achieve very ambitious things compared to large teams working with weaker tools. At some point, the quantitative advantage becomes a qualitative one. Small teams are able to do things that large teams simply can't, and small codebases can be worked with in ways that large codebases simply can't.
This market opportunity is traditionally exploited by creating abstractions for other developers to use: a database; a language; a library; an OS.
The abstraction is sold many times, with each sale enabling the recipient to create more ambitious applications. This SOTSOG leverages those few who are capable of working effectively with abstraction.