Try working on open source Minecraft projects. You will make these types of refactors monthly. The Bukkit/Spigot API has a 13 year pedigree, 10s of thousands of developers building against it, easily encompasses 1M+ lines of code across the whole codebase and needs to remain nimble in the face of unpredictable upstream changes. Watching the work some of these developers are able to pull off will definitely give you a healthy appreciation of what sorts of refactors are possible when you commit to them.
> or is unavoidable (IaC/build scripts, shell/sql/migration scripts, config files, etc.
This is a failure of the tooling in question. We shouldn't accept shoddily built tooling as an acceptable justification for unreadable codebases. Obviously, there are tradeoffs and sometimes you just need to get the tool out the door, but when a particular tool (like a professional IaC project) becomes some people's primary programming languages, then treating those languages like second class citizens who "unavoidably" are going to just be awful to work with is just limiting the growth of the tool as a whole. Terraform modules are a great example of this—all that ceremony and hassle just for what is effectively a single function call! If Terraform had single-file modules and a better import system than "relative file paths", I'd expect we'd see a lot more Terraform code bases with smaller root module files.