"Higher order" sounds pretty functional to me. Higher order functions and all. Although I guess the term higher order function is hardly even spoken of in real functional languages because they're taken for granted.
The term “higher order” generally indicates complexity and indirection. If you can solve something first order, then that is much more preferable to a higher order (function, logic, object) solution. Higher order functions fall into the same category (you can have them if you want, but you must understand what you are getting into in terms of complexity).
> The term “higher order” generally indicates complexity and indirection.
As do all abstractions.
> If you can solve something first order, then that is much more preferable to a higher order solution.
a.k.a. "To abstract, or not to abstract?". It really depends, of course. But I know for certain I would not want to solve "mapping over an array" without the Array.prototype.map higher-order function.
It really depends. Higher order debugging is more of an art than reality, so if the mapping logic is tricky, I would definitely convert a map into a loop just so I had better access to debugging. It should never be “use map whenever possible.” Also, if you drift out of well known functional origami to more niche uses of function arguments, well, there be the dragons.
Higher order function is a functional pattern.
In some OOP languages where functions were not available (Java7), it was not possible to create Higher order function without classes.
https://en.wikipedia.org/wiki/Higher-order_function