Changes tend to be made higher up in the stack, ultimately the UI, because that has a lower risk of breaking something else. This gets very messy very fast.
Bugs in shared code tend to be worked around rather than fixed because other code might depend on those bugs — which quickly becomes a self-fulfilling prophecy.
Some functions/methods seem to be natural magnets for these overly local changes, and as a result, can wildly grow in size over time. I once analyzed how a 50-line function had grown to 5000 lines over a few years in a series of individually justifiable changes.
All of this is a downwards spiral that’s very hard to stop once it has started. “Refactoring sprints” and other heroic efforts sadly seem to have little impact in such an environment if they don’t also radically address the engineering practices that lead to the situation.
And I disagree about this being what goes wrong with architectures. From my experience this is more to do with entropy than anything else. It takes a continual input of effort to 'tidy up' change to keep things looking neat, and this is often ignored or under-estimated until it's too late. The other reason is when the architecture isn't fit for purpose so has to be bent to fit around the problem it's being used to solve, but that's a different argument.
No more than if you're repairing some damage to a wall, you want to work the repair into the surrounding area rather than just infilling and spot painting the exact area of damage.
Architecture is often fit for purpose when it is initially written, but a change comes along which requires a minor rearchitecture. The overly local change might be to piggy-back some data on an existing structure (which has subtly or not-so-subtly different scope), or add a flag to an existing method. If it's not just routine BAU - adding yet another CRUD handler - it's somewhat unusual for a slight adjustment in design to not be desirable, IMO.
My argument isn't for architecture czars or so-titled architects to be in charge of planning changes. It's that local changes often don't include enough rearchitecture because the person making the local change doesn't have the time to try and see the bigger picture. They just need their feature implemented, their bug fixed, their OKR satisfied.
I didn't opine as to a solution, but if I had to, I'd say (1) ensure modules have clear ownership who is / are invested in long term code health, and (2) ensure modularity is crisp and sized small enough that a person or a very small team could rewrite a module in a few months. This isn't enough - there's higher level complexity in the interaction between modules - but it's a start.