Given their definition of procedural, the term makes sense. The book is about processes and procedures that describe how they're executed or things are computed, versus describing what is computed (mathematical sense, declarative or more declarative, closer to some popular meanings of functional programming today).
They define functional programming as "[p]rogramming without any use of assignments". Which would be a subset of procedural programming in the sense that they mean it.
They also contrast imperative and functional programming (the first being with assignments and mutations, the latter without). Both imperative and functional programming can reasonably fall under procedural programming using their definitions.
The fuller excerpt concretely put in §3.1.3 "The Costs of Introducing Assignment":
"So long as we do not use assignments, two evaluations of the same procedure with the same arguments will produce the same result, so that procedures can be viewed as computing mathematical functions. Programming without any use of assignments, as we did throughout the first two chapters of this book, is accordingly known as functional programming."
They define functional programming as "[p]rogramming without any use of assignments". Which would be a subset of procedural programming in the sense that they mean it.
They also contrast imperative and functional programming (the first being with assignments and mutations, the latter without). Both imperative and functional programming can reasonably fall under procedural programming using their definitions.