e.g. if you have 10 items to store, then a simple file may be a pragmatic choice. When it grows to 10,000 items you may need a database. But if you started with a database for just 10 items, people would complain it's overengineered.
If you have 2 classes, an if/else can do, but at 20 you need some Factory pattern, which would be an architecture astronautics if done from the start.
And when you try to anticipate such growth, you'll create overcomplicated code whenever you guess wrong.
A continuously developed project will systematically keep outgrowing itself.
It's good to learn from our mistakes. But if there's one thing I have learned from working across teams and orgs, it is that basically everyone works with imperfect information. And oftentimes, you just have to make do, write the code, and try to make room to course correct in the future.
The first character wishes to remove the fence because they don't see a good reason for it. The second takes a different approach: first show that it isn't necessary, then remove it.
Plenty of things are made useless over time. But there are also lots of things that look useless but aren't. We don't know, a priori, which is which, hence the need to be cautious.
(That said, I think there are also cases where ignoring Chesterton, removing the fence, and seeing what will happen is the best option. It just requires good planning and good testing so that you can be confident that a bull doesn't suddenly appear out of nowhere!)
Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).