I've found that many codebases in large companies degrade over time
No, I find what degrades is (a) the existence of staff who understand the code, and (b) the correspondence between the understanding which staff have of the situation, and the concepts encoded in the structure and naming scheme of the source code.
What differentiates a codebase that can be refactored, from one that cannot be feasibly refactored?
A codebase that can be refactored is one where staff are retained who are still fully in control of the code, in that they continue to possess a strong understanding of the code, the business purposes for which it was written, a strong understanding of exactly how the existing code lacks quality, the implications of proposed changes and refactorings, and the resources to execute such changes.
A codebase that cannot be refactored may lack any of these ingredients.
In the same way that a lot of rocket engineering from the 1960s is now lost to our understanding, often codebases reach a point where so much understanding has been lost that it makes more sense to start again on producing source code, than to try and adapt what already exists.
Many codebases are prematurely damaged by two things.
One is relentless development and accumulation of complexity in the source code to fulfil too many minor or auxiliary functions, to the extent that the development team cannot remain in control, and cannot continue over time to adapt the source code to serve its major and fundamental functions. This leads either to increasingly slowed development times approaching sclerosis, which stop the software being re-adapted as quickly as would be desirable, or it leads to changes being hacked in which then permanently destroy correctness or which grossly exacerbate the complexity of further change.
The other is the rapid loss of development staff responsible for the creation of source code and who have the most complete understanding of it. Second (or further) rounds of staff are introduced to work on the codebase who have had little or no contact with or supervision from the original creators, and this leads to rapid collapse both of the capability of the staff and of the coherence of the concepts embedded into the source code.
Both cancers can be related, in that excessive complexity makes it difficult to recruit further staff and reproduce the necessary understanding for them to work effectively on the source code, and failure to retain staff who are properly in control often leads to proliferative complexity in the source code which nobody properly understands (not even the creator).
It's why "pressure from above" is often so destructive for software development, because it often leads either to turnover as developers reject unreasonable additional stress, or it leads to modifications of source code that may meet short-term objectives, but which undermines the ability of the staff to maintain a controlling understanding of the source code, and therefore rapidly erodes the ability of the staff to adapt the source code further.
