I guess nowadays you can summarize the whole book into "never push to main branch directly (unless it's a small project)", "have CI/CD with PRs which you code review", "branches cause distance between developers", "branches should be as short-lived as possible". That's about it, from the things that will be useful for a today's software engineer.
Yet, it gives very interesting history on CI/CD, VCS systems, and how PRs and the now-common "trunk based development" became a thing. If you're very much into those subjects, and want to master your knowledge on this, this book may be a quick useful read for you to catch up on this. That's why I still liked it, and not regret reading this.
Things I really enjoyed: Branches create distance between developers and we do not want that. Don’t break the build, always stay release ready. High quality code by promoting code reviews and pair programming.
A very clear and no-nonsense book highlighting single branch model of work, commonly known as GitHub Flow. This book abstracts it and covers a lot many aspects of the benefits, pitfalls and trade offs in the context of CI and CD.
A good 1 day read for architects, developers and EMs.