If you find that your private key has been compromised, then you have another problem: the whole world has a public certificate in which your CA claims that you are the sole owner of that private key. You can not recall all those public certificates. The solution that has been implemented is that the CA also maintains a Certificate Revocation List (CRL): if you report to the CA that the certificate is no longer valid, then the CA will put it in its CRL. You should hope that your - unknown - communication partners take the trouble to retrieve the CRL and consult it EVERY time that they use your certificate; otherwise they will talk with Zorro unnoticed. In practice, this is usually NOT done.
CRLs are also very outdated: instead one has developed the Online Certificate Status Protocol (OCSP) that allows you to retrieve a status of a certificate from an Internet service.
OK, this is also wrong with self-signed certificates: there is no CA, so no CRL. On the other hand, you use these with 1: 1 connections so you know who your communication partners are and you can let them know that they need to remove your self-signed certificate from their truststore.
This is also an argument against using a public CA within your Intranet: then you need to make an excursion over the Internet to your public CA for each internal connection, in order to check the CRL or OCSP server. Or alternatively you need to regularly, e.g. daily, import the CRL of your CA into an internal OCSP server: but then you'll run behind the facts even more.
OCSP also does not work well: the service at the CA receives a massive number of requests and usually can not process the load.
So, one has come up with something else: TLS Certificate Status Request also called "OCSP stapling". In this case, the certificate holder (the website) first presents its certificate again to the OCSP server of his CA, and has it staple a signed time tag to his certificate, indicating that the certificate was still not revoked at that moment. If the client then requests a connection, the service sends that labeled certificate as authentication, and the client can decide if that is good enough and will not himself retrieve the status of the certificate from the OCSP server.
I think that's a very poor solution: a Certification Authority issues an ID which is valid for some time, but needs to be confirmed over and over again. What is the use of such a certificate? Imagine having a driver’s license valid for 10 years: but every time you step into your car to drive on the digital highway, you must first visit the town hall to get a stamp that your driver's license is still valid.
Limited validity, CRL, OCSP, Stapling: it's always "too little, too late". IMNSHO PKI is "broken by design" at this point. Not that I know a solution for this, otherwise I would not be where I am now.