> at what point do we tear it down to see what happens?
Without knowing the purpose of something, we cannot know the cost of removing it.
A few weeks someone commented to me on how they thought that some chain link fencing along a railing should be removed because it was unsightly, until they saw a toddler playing near the railing and realized that the toddler could easily squeeze through if the chain link fencing wasn't there. If they never saw the toddler, they would have thought the fencing pointless. If the people they asked failed to think of the size or behaviour of toddlers, their conclusion would remain unchanged. Yet, had that chain link fencing been removed, the results have been tragic. Because of the nature of my work, I can think of many other circumstances where safety measures have been put into place where only a few people would understand their purpose. In most cases the reason is less obvious than that bit of fencing. Unfortunately, few of them have the element where someone realizes the purpose out of chance before the damage was done.
Much the same can be said of software. It may seem like it is fine to pull out a piece of code, test it outside of a production environment, and give it the okay when everything works. Yet it may not be fine. That code may have been inserted to deal with a problem that client X was having to deal with one of their requirements or to deal with a peculiarity of their production environment. Because it is particular to a particular client, the development team may not know of it (e.g. the developer who did the work is long gone) or it may have simply been forgotten. Just because the purpose is unknown in the present doesn't mean that removing it is devoid of consequence. Those consequences may range from impacting their procedures, to financial loss, to safety.
At the end of the day, you need to understand why something exists to determine if it is still relevant. It should be removed only once you know that it is no longer relevant.