How do you know no one would ever have to touch that code again, at the moment of writing it?
Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not bad code.
When you find something real blood-curdling but the last commit in that file was three and a half years ago, you just close it and pretend you didn't see. Better to spend the effort somewhere it will definitely benefit someone soon, rather than maybe some day.
The key idea is to break code into "chunks" that each do one thing.
Then, if you have to add a new feature, it goes into another chunk, instead of editing/modifying existing code.
The same logic applies to system design at different scales, whether fine-scale OOP or coarser-scale (micro)service architecture. The ideal size of an individual "chunk" is somewhat subjective & debatable, of course.
It's like Haskell-style immutable data structures, but applied to writing the code, itself.