No, there is no benefit to doing that, and in fact it likely opens a security hole. Let my explain.
First, a metaphor. A bouncer at a bar asks for your ID. The normal system is for you to present your ID (metaphor: client cert), the bouncer checks that the ID legitimate (metaphor: validates the issuer, revocation, etc), and checks that the photo matches the person standing in front of them (metaphor: the client cert will digitally sign part of the TLS handshake using their private key). You are proposing that instead of accepting the ID presented to you, you should take their name and go retrieve the ID from a government database. This is only necessary if you don’t have a good way to check legitimacy of the ID on the spot. That may well be a weakness of physical IDs, but it is not a weakness of digital certificates. If the issuer signature is valid and the cert is not revoked, then it is authentic and you would get the same certificate from the CA or domain owner. So the extra lookup is not necessary.
I said your suggestion might open a security hole; let me explain:
As part of TLS client auth the client will perform a “proof of possession” by signing part of the TLS handshake with the private key that matches the certificate. If you (the server) go off and get their “real” certificate, maybe they have multiple valid certificates, how do you know that you’re getting the one that matches the private key they’re trying to use? Also, how are you going to do the lookup, with a name (DN) that the client gave you? How do you know that they are not lying to you and getting you to look up someone else’s cert? So the extra lookup may in fact introduce vulnerabilities.