The main value in software is not the code produced, but the knowledge accumulated by the people who produced it
Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.
You are thinking just the running system.
The decisions behind why, the quirks of the software, how that all fits together, and the knowledge of why you should do certain things (like monitoring, experiments and whatnot) is important.
Good luck documenting all that. Good luck making that document discoverable and readable.
accumulated doesn’t allow any qualitative judgement about the way they treat that knowledge. So we shouldn’t assume the worst.
I suggest the opposite: if they take their own words seriously and this knowledge is the main value than I’d assume they grow in great lenghts documenting that main value — because it would be (as you rightly noticed) lost.
My take on this point (and something I agree with) is that you shouldn't get too attached to a particular implementation. It can be useful to build a prototype and throw it away, then use that knowledge to build a better version, than to try to keep building on top of the prototype.
There's nothing in their point that refers to documentation.
I would argue that to any experienced software person, in the context of a project the code means "code and documentation" (containing domain knowledge, implementation history and intent inexorably bound together as one unit). Whereas, the quoted phrase suggests a dichotomous perception.
Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.