Software development has only comparatively recently realised the importance of version tracking and history maintenance.
Software packages were available 40 years ago to do the job for mainframes, but a lot of people preferred just to swap the punchcards, if they could find them. (I remember one DP manager who was horrified at the waste of precious disk space incurred by a source code library. I wonder how much money confusion cost his shop?)
Online systems obviously stored code, but didn't necessarily track its history. It's taken several generations of control packages to curb the anarchy.
I enjoyed your article and thought that I would respond with a few observations of my own.
First, back in the old days, every drawing and every document contained a 'Revision History' section that minimally detailed why the drawing/document was revised and when. Revision costs (and resultant delays) were closely managed between the contractor and the customer. Change Orders were all tightly managed and contractually based.
I watched processes evolve over time to where projects were managed by first generating an FRD (Functional Requirements Document) which needed to be signed off on before any actual design work began. Then the FRD was followed by an SDD (Systems Design Document) which mapped the customer's requirements to the actual design. And this design document was signed off on before any actual fabrication began.
Progress was measured via a TEMP (Test Evaluation Master Plan) document that measured the progress and adherence of the design to the customer specifications.
It has been my observation that the cost and impact of revisions lost some of their trackability over the course of my career due least in part that my career began in a very visible P&L environment (industrial construction) and ended working on enormous government contracts to where change management wasn't as tightly controlled.