> There wasn't any implication that the code is "brittle" or hard to grok due to a defect in the software architecture
Re-reading my comment, it comes off dismissive - I apologies for that. I agree with most of your points
> Some types of software are intrinsically difficult to understand e.g. due to highly visible behavioral coupling across multiple unrelated parts of otherwise tidy, modular code. This is a strictly correct and intentional design in many cases but it means even a seemingly small code change can only be evaluated for correctness relative to the detailed internals across diverse code components in various runtime contexts
Sometimes - the above is the case, but other engineers are unable to maintain those hard parts because the information required to do so is in the heads of the experts (the original author, or the 2nd engineer). In those cases, docs may help, but sometimes the code exhibiting unexpected coupling and/or side-effects may need to be further modularized, OR paradoxically, consolidated and abstracted by an easier-to-keep-in-mind abstraction as the "modularization" is illusive since the seemingly independent modules covertly belong together.
I may be projecting because of my past experiences: at different points I was the only one who could make changes to specific modules, one because it was brittle and had low test coverage (and prone to race conditions), and the other time, it was because there was non-obvious coupling which resulted in high cognitive load as one had to keep several layers of state in mind. On both occasions, refactoring and improving the abstractions would have made it easier for other engineers to safely work on the code.
YMMV if the high-cognitive-load architecture is deliberately chosen - in my case, it was an accident of (commit) history.