Writing documentation of any kind is generally quite a hassle. Usually, it brings about as much benefit as harm. Writing unambiguously understandable is difficult, making sure it's read is difficult, keeping it up to date is very difficult.
Any "how to write code" guidelines that some developers on a project write for others are no different in this sense. And the temptation is quite large. You supposedly once wrote in human-readable text such a law that people should now adhere to. Then you hold people accountable for violations of this law in code reviews, throw a link to the docs instead of rewriting everything to everyone. But almost always - this is a half-measure and a crutch.
In practice, this is useful perhaps only for some onboarding. That is, when you're new trying to get familiar with the culture or some new approach in the shortest possible time. Or you're old, you remember that you have documentation, but don't remember what's written in it. Because making everyone follow these requirements is not easy.
And where's the confidence that you're even right describing the framework in which the team should work? I generally don't like prohibitive rhetoric. And if it's in words, it's always a subject of some absolutely unnecessary disputes. Everything that is not forbidden is allowed, and this is wonderful. Consistency is good, but not at the cost of all flexibility in decision-making. A developer in a specific team knows better how to write a feature.
The legacy question on this issue is also very difficult. You will obviously improve your approach. Where is that line where we hold accountable for violations of current guidelines and force to rewrite, and where not? What if a person got into legacy that's 10 years old? What if they touched 1 line? Does the law have retroactive effect? Formally, the reviewer will be right.
I really like documentation describing some high-level vision of the project, some strategy there, HLD, a list of decisions made at the forks of history. I really don't like documentation that for some reason duplicates the rules of detekt or meticulously describes what classes you must have in the feature architecture. It makes things worse.
If it's important - formalize and automate as much as possible, if it's not important - let it go.