Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.

You're not wrong: there's definitely evidence, for instance, of savvy attackers watching the CT logs for things like newly-instantiated WordPress servers and then attacking them before the admins have set the initial password on them. (Which is really a WP problem, but I digress.) So there's benefit in not having the internals of your infrastructure writ large in public CT logs.

My problem is with the selected solution: wildcard certificates are a huge compromise waiting to happen. They give an attacker the ability to impersonate _anything_ in my infrastructure for as long as the cert is valid (and even a week is _long_ time for that). Worse, if I'm then distributing the wildcard to everything on my internal network that needs to do anything over HTTPS, that's a lot of potential attack points. (If it's just one TLS-terminating bastion host that's very tightly secured, then...maybe. _Maybe_. But it almost never stays that way.)

To me, it's a much better security tradeoff to accept the hostname problem (or run my own CA internally for stuff that doesn't need a public cert) and avoid wildcards entirely.

Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :)