IMO it's not excellent. It's not like SICP, it's obtuse for no reason, I find it a hard slog. Flexibility is good but it seems to try to make every bit of your program flexibile and pluggable and you just need to do something eventually.
My opinion, I'd welcome others on the book; there was a small splash when it came out but not much discussion since.
I haven't read the book, but my experience is that the way to make things flexible is to make them simple as possible.
When I've used (or built) something that was built in the style like you're talking about, it's almost always wrong, and the extra complexity and stuff now makes it harder to do right. It's not surprising: unknown future requirements are unknown. Over building is trying to predict the future.
It's like someone building a shed and pouring a foundation that can work for a skyscraper. Except it turns out what we needed was a house that has a different footprint. Or maybe the skyscraper is twice the height and has a stop for the newly-built underneath. Now we have to break apart the foundation before we can even begin work on new stuff; it would have been less work if the original just used a foundation for a shed.
I think that is what the book does. Step by step introducing new requirements, by telling you about a situation, where the previous code would not be flexible enough. I am sure it doesn't state, that one should apply all of its ideas all the time, regardless of the project at hand.
I don't know about books, but I think the best approach is functional programming in a dynamic language. That could be because I'm currently an Elixir fanboy, but I think Lisps, especially Scheme or Clojure, or a functional-restricted approach in JavaScript could do it as well. I agree with parent comment that it's better to keep things as simple as possible and make the changes when necessary vs. building in all the flexibility in the beginning.
My opinion, I'd welcome others on the book; there was a small splash when it came out but not much discussion since.