When working in languages which lack inbuilt structure and organisation features (e.g. if it doesn't have namespaces, packages, assemblies etc...) or where these are insufficient to keep a codebase of that size under control, the natural response is to develop our own strategies to organise the code.
This organisation strategy probably includes standards relating to where different files should be kept, things that need to happen before/after certain types of operations, and naming conventions and other coding standards, as well as a lot of "this is how it is set up - don't mess with it!" type comments - which are valid so long as they explain why!
Because the strategy is most likely going to end up being tailored to the specific needs of the project (people, technologies, environment etc...) it is hard to give a one-size-fits-all solution to managing large code bases.
Therefore I believe the best advice is to embrace the project-specific strategy, and make managing it a key priority: document the structure, why it is that way, the processes for making changes, audit it to make sure it is being adhered to, and crucially: change it when it needs to change.
We are mostly familiar with refactoring classes and methods, but with a large codebase in such a language it is the organising strategy itself (complete with documentation) that needs to be refactored as and when necessary.
The reasoning is the same as for refactoring: you will develop a mental block towards working on small parts of the system if you feel that the overall organisation of it is a mess, and will eventually allow it to deteriorate (at least that's my take on it).
The caveats are also the same: use regression testing, make sure you can easily revert if the refactoring goes wrong, and design so to facilitate refactoring in the first place (or you just won't do it!).
I agree that is is much trickier than refactoring direct code, and it is harder to validate/conceal the time from managers/clients who might not understand why it needs to be done, but these are also the types of project most prone to software rot caused by inflexible top-level designs...