Since this is HN, I'm hoping for some discussion of how this could be applicable to software documentation. I've felt similar frustration with complex board games and software, and thought often about crossover in techniques of presentation. At the least, I'd like to see software manuals have a consistent structure, like those of the old SPI wargames.
The issue with software documentation is very different than a boardgame: The boardgame is static, changes to the boardgame are ultimately changes in the documentation, and people will not pay for a game they can't understand, while people end up using systems that are undocumented.
There's good documentation in the software world, but it's always for systems shaped as to have all the incentives align to having good, current documentation. Stripe has good docs, because that's part of being able to onboard people: Bad docs cost money. Postgres has good docs because it doesn't change that much, so the good documentation stays useful, and they have a quick loop between finding errors and fixing them.
Your typical internal project has awful documentation because it's nobody's real job, the requirements change constantly, and not enough people would use the documentation in the best of times to make good documents a worthwhile investment.
And if you ask me, the SPI wargames aren't exactly pinnacles of good rulebook writing. If anything, the similar shape came from the games themselves having similar bones, more than because the system was good, or because standardization helped.
