There's really no reason to avoid wildcard certs for your domains, unless you have so many subdomains that are managed by various business interests.

I use LE wildcard certs and they're great, you can use them internally.

It seems like the principle of least power would apply here. There's value in restricting capability to no more than strictly necessary. Consider the risk of a compromised some-small-obscure-system.corporate.com in the presence of a mission-critical-system.corporate.com when both are issued wildcard certs.

Wildcard certs are indeed a valuable tool, but there is no free lunch.

You'd usually put a reverse proxy exposing the services and terminating TLS with the wildcard cert.

The individual services can still have individual non-wildcard internal-only certs signed by an internal CA. These don't need to touch an external CA or appear in CT logs - only the reverse proxy/proxies should ever hit these, and can be configured to trust the internal CA (only) explicitly.

A compromised wildcard certificate has a much higher potential for abuse. The strong preference in IT security is a single-host or UCC (SAN) certificate.

Renewing a wildcard is also unfun when you have services which require a manual import.

Renewing any certificate that requires a manual import is not fun. Why are wildcard certs less fun to manually import than individual certificates?

Presumably one purchases a wildcard for multiple distinct systems.

Using them like that never occurred to me. I was thinking multiple sites on one host or vanity hostnames: dfc.example.com / nullindividual.example.com. etc.

Unless you're running some sort of automated system to churn out vanity host names (like an Azure or AWS would to provide you an OOTB URI), a UCC/SAN cert is a better choice.

More restrictive is better than less restrictive when it comes to certificates.

Yeah, I switched to wildcard certs at some point for this reason.