Last time I tried I got as far as the first substantive program (https://github.com/norvig/paip-lisp/blob/main/lisp/gps.lisp), was generally confused by the code, and was then not surprised when the following sections pointed out all the faults (i.e. bugs) with the initial approach and suggested various improvements. I've come to trust my own "how can this possibly work?" confusion as a strong signal that a design is probably buggy or fragile, so it was nice to see it confirmed here.
Which is not to say that what this book teaches is not useful, but I wouldn't go to it looking for best practice and robust software engineering techniques. Much of what I saw in this book wouldn't pass code review in many situations ("too fragile" or "too clever"). Most of what he's talking about are techniques that "allow a programmer to delay making decisions". This is a different kind of programming than very the very concrete kind of programming that can dominate day to day professional work. I suspect that these kinds of "delayed decisions" are best applied sparingly, but applied correctly they can be powerful.
To get a flavor of the "Norvig approach" to things, his Advent of Code solutions in IPython notebooks are fun: https://github.com/norvig/pytudes