This highlights an issue with "code as documentation".  It fails to distinguish between implementation decisions that were arbitrary and those implementation choices that are crucial for correctness.

Someone writing a new bitcoin implementation could focus their energy on what is important to get right vs. something that "just happened" to be done that way and could have been done otherwise to no ill effect.

I'm aware of the argument that reimplementations must match the Satoshi client bug for bug in order to prevent a divergence of consensus, and that such divergence can carry a high economic price.  However, unless the reasons for any given behavior are written down, as the original developers move on, this tribal knowledge gets lost.  It is replaced by the guesswork of future developers.

The consensus of the development team seems to be that even if a well-written protocol specification were completed, they would not feel bound to consider it authoritative.

So be it.  But as bitcoin implementations need to go beyond traditional "software on PC" (think POS terminals, embedded systems, smartcards, dedicated silicon nodes, etc.), without a specification to test against, it is very difficult to assure quality and correctness.