I think _entirely_ ignoring the kinds of considerations it covers is such a typical failure case for inexperienced programmers (or non-career coders) that it's an excellent prod to expand the scope of what enters their awareness when writing code.
Ideally folks notice discrepancies between their experiences and the things it recommends and find their taste and judgement that way, though it doesn't always work out.
So like, maybe the fact that some of the advice is clearly dreadful if you try it could be a useful wedge against the kind of cult thinking so pervasive in software. I've seen considerably more grief from people treating his SOLID stuff like a bible that clean code. YMMV.
Important to note that the book is an adaptation of content from Sussman and Hanson's Adventures in Advanced Symbolic Programming course[1]. My sense is that the 'Flexibility' angle is a bit of a misframing, making it sound more like a rough and tumble best practices book, rather than an elaboration on neglected idioms from symbolic programming that they feel deserve wider adoption, paired with blue skies ideas on how to make software robust.