Not long, but perhaps not for the reasons you think. With the code base frozen, no new incompatibilities can be introduced. That's how software (including operating system) releases worked for many years, and they did work. VM/container images are still basically this way, and they tend to keep running quite well too. One problem with both of these models is that existing security vulnerabilities don't get fixed, but that's not code rot. It's a serious but separate issue.

No, the way I think a frozen codebase will rear its head is when things that haven't been restarted in too long start to misbehave. When new updates are being pushed out frequently by a busy team, every machine (container, process, whatever) is being restarted regularly. People don't even realize what they're avoiding each time. Resource leaks, deadlocks, and timer issues can remain undetected a long time in that environment, then surface when the longevity increases. Even worse, some things tend to fail after a predictable amount of time, i.e. across most or all machines at once in a cluster.

I first saw this in 1990 at Encore, when our shiny new SMP version of UNIX became capable of staying up for a whole month at a time. Because of problems like those mentioned above, getting from one month to two took almost as long as getting from zero to one. I've seen the same scenario play out on many other systems since, and there's no reason to believe the systems within Twitter are immune.

Stasis is not the same as stability.