No OP but I used to work at a large company with a similar number of repos.

When I left about a year ago, we had just started (after being on Github for almost 8 years) an ongoing project of first archiving old/outdated repos in place, and then moving them to an "archived" sub-org, and waiting to see if anyone complained.

Previously no one wanted to outright delete or remove repos because of the risk that someone somewhere was relying on it, and also there was no actual downside to just leaving them there (no cost savings, no imminent danger other than clutter, etc), so resources were never allocated to do it. There was always something more important to work on.

In an org with a higher floor of engineering management, a proactive program for removing unused or outdated repos would absolutely be expected though I think.

This is a continual fight for me. At nearly every company I've had to compromise on using a graveyard repo for packages within a monorepo, even though git has the whole history already.

The problem with history is that you need to know when to look. If you're looking for some old code that you know existed but you don't know exactly what it was, you can't just browse to go and find it.

Sure, but beyond a certain point the code that's there isn't just drop in compatible.

Gitlab is so nice for this. You can group repos together so it is harder to lose track of stale projects.

Breaks old stuff