I think your conclusion is a result of oversimplifying the concept of Chesterton's Fence. The idea can be restated as "Don't remove what you don't understand", but that doesn't imply "This thing is impossible to understand and may never be removed". A lack of understanding at a point in time doesn't imply a permanent inability to understand.
Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).
Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).