SICP Section 1.3
High order procedures are a very powerful mechanism for designing procedures. In languages that support it, one can pass procedures into procedures as arguments, or similarly have a procedure which returns a procedure as it’s result.

One first blush this sound like a lot of complicated gobbledygook, but being able to pass in procedures allows one to factor code to capture common patterns and name it as a new abstraction, via a procedure, which can be written, tested, and documented once. An example from the Ruby world would be File#open method given a block. This procedure accepts a block executes the block in the context of an open file, and lastly closes the file. The user doesn’t need to remember to do with, if they pass in their “read file” procedure which takes one argument “file-handle” then they don’t have to duplicate standard file code.

Being able to return procedures from procedures, I image, would allow one to parameterize the new procedure. One of the annoying things about Java’s object constructors is that they can not create and return a subclass. So one ends up adding static “creation” methods, so that you can parameters the object you give out. High order procedures don’t have this limitation and you can dynamically build a function based on the inputs the the current procedure.

In a way this is run time code generation. I think this makes it harder to reason about the code, and it use probably really shines when it clarifies an idiom and captures it, but it could be needless complexity or obfuscation when used without purpose.

This “first class” notion of functions, where you can name them by variables, pass as arguments to procedures, returned as results from procedures, and be included as elements of data structures, increases the faculty for building abstractions.