This is why you see design doc culture at Google as well. At my startup I pushed for an RFC culture to flesh out ideas and break stalemates just as the author describes. I called them RFCs because we don't have a tool that versions documents, so if we need to make amendments we mark older RFCs with newer RFC extensions or supersede them.
There is also a large benefit to other engineers getting up to date on a system, why things were done a specific way, why a technology was chosen, what tradeoffs were considered and why.
Could you elaborate on what an "RFC Culture" means to you in a broader sense? I feel like there's a train of thought here that I'm missing and am keen on further elucidation.
What would a documentation or comment-chain ideally be constituted of? How would you change existing docs in a practical way which would reflect both deprecated and replacement functionality?
When you originally considered "RFC Culture" what system did you have in mind?
There is also a large benefit to other engineers getting up to date on a system, why things were done a specific way, why a technology was chosen, what tradeoffs were considered and why.