I think you are interpreting "go read" as in go learn these by rote. He's not saying go memorize the details of these Unix and TCP books. He's saying go read them and absorb their gestalt approaches to decomposing complex systems so you can think about your own problems that way.
To this list, I would also suggest compiler construction or database systems as different topics exhibiting the same thing.
A more basic challenge for a scientific programmer might be absorbing the mindset of tool building rather than problem solving. It's a different mental perspective to think of your code as a product for other developers rather than as a means to producing a data artifact.
I would be interested to know why you think of them as unnecessary details.
What I like about them are that they describe large complex systems that have to work with a bunch of people plugging in their own implementation of the parts. For me, both books give a good sense of what you need to do to enable the product you are working on to evolve successfully, and highlight areas where a lack of flexibility impacted that evolution.
So often in programming you look at your code and have to evaluate not only what features you are delivering but also what paths you are closing off with your design. In my experience the folks who excel at programming hold both the model of the system in their mind while they execute some part of it.
To this list, I would also suggest compiler construction or database systems as different topics exhibiting the same thing.
A more basic challenge for a scientific programmer might be absorbing the mindset of tool building rather than problem solving. It's a different mental perspective to think of your code as a product for other developers rather than as a means to producing a data artifact.