Why are books so prevalent in the DevOps community?
In most cases, the recommended books are not about technology. While technology changes, the fundamental principles behind organizations like system thinking, leadership, common sense, etc... do not change as often.

Books such as The Goal, and even The DevOps Handbook do not mention much technology on their pages but rather ways to manage work being performed by people.

Many problems are technology related, topics such as Microservices, Architecting large-scale systems, Infrastructure as Code, etc... these don't talk about a specific tool and/or technology but rather about an architectural topic. A field of knowledge that people who build large systems need to know in order to build the system correctly. This knowledge is rare, and its great the books are written about these subjects - just disregard the tools mentioned, or translate into their new-er reincarnation.

One of the better books about creating quality software (imho) is Agile Software Development, Principles, Patterns, and Practices. And while the language used in this book (Java) has moved along quite a bit, the examples provided in the book are timeless and can be easily translated into any other language of choice.

Some of the problems the DevOps movement tries to solve are involved with common ways work is managed in organizations that just doesn't make any sense. As Eliyahu Goldratt often said (author of The Goal) "Common sense is not very common".

These books teach principles of thinking correctly about problems and human relationships in a system setting so that the whole system is improved. The lessons are old, and unfortunately, only rarely there are people who work in the field who actually learned them.

Naturally, there are also authors who wrote books about such and such fizz-bang tech tool that is new and relevant to the field, like AWS or Docker or Jenkins or whatever and just want to push their book sales ... but I try and exclude these kinds of blog posts from my answer.