I think the main reason codebases are ever-growing is that we never ask, in a serious way, the question "could this be much smaller". I can't recall a company where there was ever a concerted effort to consistently refactor a codebase for conciseness, nor where the inevitable breaking changes from that activity would be tolerated.

It is difficult to find an economic argument for such activity but it bears a significant resemblance to a "tragedy of the commons" scenario.

By contrast, if I look at my large private codebases, which I religiously refactor and modernize every few years if I think I could improve them even on elegance grounds, have shrunk in size and complexity by a significant integer factor over the many years. And this observable shrinkage happened while adding significant features and materially improving scalability, performance, parallelism, and robustness. The difference is that I can break my APIs and architectures anytime I want and the only person who is mildly inconvenienced is me, and I don't have to justify the time spent doing so.

If I look at the mechanics of how the shrinkage happens, I invest a lot in building highly refined code tools that replace recurring development patterns seen across codebases, and then deploy them everywhere that pattern occurs. It is a kind of inductive library building, done to high standard. Again, not a pattern I see much in other large codebases. If the code works, we rarely change it, and it is difficult to justify this kind of tool building when we could be shipping features instead.

I understand why the incentives in engineering organizations of any size will never encourage working this way, except outside perhaps the occasional small team. There is a strong bias toward maximizing convenience and minimizing transaction costs in the moment, which are felt keenly. Whereas, the significant drag on productivity and maintainability is highly diffuse and only felt over a long time.