Earlier quoted context omitted.
Unless the exploit makes unreachable code reachable. Security (and privacy) are largely about minimizing surface area.
The "surface" in "attack surface" implies reachability. Your argument doesn't make any sense, how would "the exploit" make an unreachable vulnerability reachable without being able to execute the vulnerable code in the first place? Please don't say "using a different vulnerability that allows us to execute arbitrary code".
Sorry, but I'm going there anyway. Imagine two different exploits. One is a remote code execution exploit and the other is a privilege escalation exploit.
Let's say your application has an exploit an attacker then manages to obtain a reverse shell (imagemagick, xml parsing, etc all have had multiple such exploits over the years). If you're running things correctly, that reverse shell is not privileged. It's the apache user or something. Not a good situation to be in, they can do a lot of damage, but at least some things are safe. They don't have root.
Now the attacker finds that you have X11 installed. It's an old version that was installed by default. It happens to have a root privilege escalation exploit via fonts. Now the attacker has root.
That's what I mean by surface area. Thinking in terms of "have we been compromised" isn't sufficient. Being able to contain the attack is important, and dead code lying around factors into how well you can contain it.