Sure 'nuff, I'll try to explain.
First off the reason I fiond it cryptic and inefficient is that out of the gate it is inherently spaghetti code. REAL spaghetti code liek the term was used 30 years ago, not the bizarre "let's throw the terms at anything we don't like today".
It spreads out the simplest of operations across two to ten times the code needed to do the job. The order of execution is all over the place so following "this function calling that function which calls that other function" when said functions are all over the code or even in different files, is like trying to follow one noodle from end to end in a pile of tossed spaghetti. That's what the term means regardless of how many people vomit up the term now.
Functional programming is INHERENTLY spaghetti code, as in most all cases you're spreading out code in a serpentine fashion that doesn't need or warrant being spread out!
The use of Array.map is similarly flawed in that you're introducing the overhead of function calls to each iteration. People seem to have this crazy nonsensical idea that calling "map" avoids looping. It's still a freaking loop! It's just hidden inside the function.
By using a callback inside it, all you've done is introduce the overhead of a fuction call to EVERY iteration of the loop. If we were talking a compiled language that's a push of the program counter, push of any arguments, load of the program counter, copy of the stack pointer to the base pointer, running the function, restoring the stack, and then popping the PC... in an interpreted language like JavaScript this only gets many many times heavier, introducing a dozen extra program steps EVERY blasted time the callback gets called!
As such it's not performant code any more than it is clear! If we just say a normal for loop it's far clearer what it's doing, and we skip all that wasteful overhead!
And it gets worse when people chain these result building methods together, such as sending the result of main to filter to reduce to etc, etc, etc... making copies of copies of copies of what would/should be built in a single loop instead of two or more loops with two to ten times the callback overhead and two to eight times the memory footprint / garbage collection thrashing!
That's why it's bad practice! These "short functions for NOTHING" create spaghetti code and introduce execution overhead. It's even more nonsensical to call them short given you're ADDING code for nothing in the form of these pointless tiny functions! The only reason it might SEEM short is the use of gainfully cryptic trash like arrow functions; aka "wah wah, eye dunz wunnu half two tiep teh wurd funzion!"
I swear the direction modern JavaScript is going, people won't be happy until it looks like brainf***! This lack of verbosity, overuse of cryptic symbology, and so forth undoes the entire reason to use a high level language in the first blasted place!
Which is why it makes sense you compare it to algebra, because to me it reeks of people seeming to think that they need to translate "See Spot, See Spot Run" into vector calculus!
But then, I'm from the age where if your code is complex enough for "re-use of high order functions" you've likely ridiculously overthought the answers to your problems.
I'm gonna write a proper article about this with some benchmarking just to show what I mean.