His expectations around producing documentation go only as far as "Think about what documentation or data users need to understand and use your solution." That seems like rather a low bar, compared to items like "I can articulate how all the data I use is laid out in memory." I'd prefer to live in a world where a professional software engineer was expected to write documentation, and expected to be competent at it.
That's not a high bar, it's an arbitrary hoop. It'd be like saying "I always know which processor cache my variables are sitting in". In modern languages it may be literally impossible to look at a block of code and know what's sitting in the heap vs. on the stack, and the heap is often broken into many different components only fully understood by the compiler/interpreter/VM writers. We want to abdicate responsibility of this kind of memory management to the interpreter, just like we want to abdicate responsibility for handling processor cache levels. If you can articulate how all the data you use is laid out in memory all the time, you are majorly micro-managing the runtime.
Agree with the documentation thing though.