Keeps from changing up too often but also gives a conscious evaluation.

Architecture should not be "we have always done it like this". If you don't write down why though it will become that. Often there are good reasons that things have always been done like that - those reasons may or may not still be valid but if you don't know what they are it is hard to evaluation. More than once I've seen someone rethink a "we have always done it like that" and discover the hard way why they always did it that way.

I've never seen a company with a good way to write down why they do things though. When someone even tries nobody reads those documents.

Then when new knowledge/technology/idle cycles come along they can take advantage to update/refine it in sensible ways.

Often the sensible way is "leave it, it works fine". But there's a big difference between arriving at that outcome via ignorance vs. deliberation. Too often management doesn't recognize the difference, but the former as your state of affairs will eventually lead your stuff to rot.

The metrics I think you’re referring to are the ones you collect throughout your product, which I think the article author would advocate you continue to collect and expand.

The “metrics” the article references is more actively tracking and referring to them in your workflow. So, tracking and acting on changes to conversion rate. If you “expire” them, you don’t stop collecting them, you just take them off your dashboard for now.