I think you're basically right, PKI implementations are horribly complex in practice and doubly (or more!) so with Windows.
It seems to get worse as certificate-based security gets added into products as defaults installations. As an example, Exchange 2016 installs a self-signed certificate by default which gets assigned to SMTP and IIS. The normal (spanning back several releases) process of adding and assigning a public certificate to services doesn't change the self-signed certificate assignment and use for the IIS Exchange Back-End site or for transport connectors.
I ran into these are problems recently with a customer who deleted the self-signed certificate after installing and assigning his public certificate. Bam, dead Exchange GUI -- had to re-bind the back-end Exchange site in IIS with the public certificate.
Another customer had "verify certificates" enabled on their spam service and when they switched SMTP delivery to the new server, the self-signed cert was still being used by the front-end receive connector. It took some kludgy, un-documented Powershell to force the connector to use the public certificate -- ie, the attribute has to be built as a compound variable using sub-attributes of the public certificate combined with some text, and then that variable assigned as the TlsCertificateName on the connector.
So even if you're trying to use certificates, application behavior and certificate selection is pretty opaque in many cases and can actually ignore specific certificate assignment options.
I won't even get into the management trainwreck that is Windows certificate server, with its 2003-era dialog boxes and management tools. In my mind at least, all of this could be modernized and made much simpler to manage, but the toolchain remains completely user-hostile.