Focus on just the Caddy setup and TLS certs for now. Once you are happy with that, then look at Authelia.
Authelia has an integration docs example for Caddy, you don’t have to use the OIDC/OAuth2 support it has (for your services to delegate login through), but you can use it with the Caddy directive forward_auth for a central login process as an auth gateway (if you’re familiar with basic auth, this would be an improvement on that).
They have a Discord community where you can get assistance if you need any. Authelia is configured with YAML, while you can find alternatives that have CLI or Web UIs / APIs to use instead.
Yeah it’s nice, but again just try narrow focus on what your basic requirements are. Get that working and then explore these nice to haves, I sometimes talk about them like they’re a walk in the park and while they’re fairly easy once you’ve invested the time to grok it, I was quite slow to adopt each of these myself due to how unfamiliar I was and concerns with doing so securely/correctly 
Yeah, CT (Certificate Transparency) logs the public provisioned certs. So a wildcard is useful there when your FQDN would reveal insights into what services you’re running, which due to the historic and searchable logs, an attacker could query to get a broader picture of your infrastructure. It’s not usually a significant vector to be concerned about, wildcard certs do have their own disadvantage if the attacker compromised your private key for that too. Depends on the trade-off you’re comfortable with.
I’m not really a target of notable value, so my threat model to protect against is simpler. If you think about it from the attackers POV, they are usually automated or going for low-hanging fruit (scanning for exploits and the like), they might get involved more directly when that automation identifies such opportunities but otherwise you’re just one of many and they only have so much resources to budget.
Anyone carrying out a targeted attack may have more resources (time, money, etc), but they’ll likewise have a cut off point too - unless they are very determined in which case they’ll probably be successful (either by skills, or other affordable avenues of attack).
You only need the root CA cert in the client trust stores. Beyond that you have Caddy managing the leaf certs for each service (or a wildcard leaf cert), which the client receives to verify trust against before establishing TLS.
Thus for internal usage with a private CA, it wouldn’t matter too much AFAIK. If you want the convenience of clients using an already trusted CA like LetsEncrypt you can go the public route instead and prefer a wildcard.
In Caddy this may be a little more annoying to manage with handle directives as a workaround (see this comment which talks about the same topic for more info).
This is regarding the LetsEncrypt approach instead of managing private root CA certs (Smallstep or Caddy generated)?
You can rely on the public DNS to point to an internal IP if you like. It’s a little bit of information that leaks I guess, but it’s private range and likely very common. If the attacker had access to your network they could do some port knocking, it’s unlikely to be too big of a concern.
If you don’t need that convenience of public DNS, because the clients are all connected to your router and get your own local DNS queried without needing additional configuration, then that’s fine too and you won’t need public DNS records for such as your clients go through your private DNS service first anyway.
If you do go with LetsEncrypt and Cloudflare DNS challenge however, then it’s a public TLD. Not an issue since you own the domain. If you choose to go fully private/internal, use a special-use TLD (like .home.arpa or possibly the recently approved .internal, definitely not .local), and these should not risk leaking to public DNS (.internal might take a while for broader adoption of rejecting it, not sure).
There is pro/cons to whatever approach you decide to go with, and that varies based on your requirements/comfort.
I can’t comment on OPNsense, I am aware of it only by name. Along with others like PiHole, it’s just not something I’ve dabbled with.
My usage for self-hosted services is still very much ephemeral, so I have it all configured internally to bring up/down. I used Smallstep CA in the past with ACME for provisioning certs for a mail server, but usually I just have Caddy manage the certs works for me, or I provide Caddy with a cert I created externally via step-cli.
If you’d like guidance with how I use step-cli, I gave some examples here, 2 commands to provision root + leaf certs, 1 command to add root CA to trust store, then add tls directive in Caddyfile for leaf cert (wildcard).
The cert is a public key, it’s not a secret and is used for HTTPS / TLS. The private key is a secret that should be kept safely. You’ll want to do that regardless of how it’s provisioned as anyone with that private key is able to claim to be the server the certificate was granted for (the explicit FQDN or wildcard).
The root CA (and any intermediates) are similar, but they tend to have longer expiry dates and are used to provision your leaf certs. Intermediates aren’t required to provision a leaf, just a best practice so that the root CA cert (which is what clients have in their trust stores) can more safely secure it’s private key, where it’s used to renew intermediate certs that then provision the leafs.
Look at the link I provided for step-cli examples if it helps. You can technically throw away the private key for the root CA if you don’t intend to sign anything with it again (which is fine for manual provisioning if you’re comfortable updating each client store again). Since my usage is typically disposable setups, I don’t really need to proactively protect this secret so much as I don’t have external clients to update.
In a proper production scenario you’d have automated renewals and your root CA cert is not something you want to update on each client frequently, so intermediates are worthwhile. Should an attacker gain access to the private key on the filesystem for the intermediate, you’ve probably got bigger worries with your security
Now that I’ve probably clarified more about cons with the fully private approach, and your own experiences trying to pursue that… you can see why many prefer to just go with LetsEncrypt and public DNS 
Your wildcard cert would still have the private key stored on the filesystem, you can look at Caddy docs for where that’ll be stored. If the attacker could compromise access to the private key for that, they’d likely be able to do the same without a wildcard cert when you have it all managed by the same Caddy instance, so that disadvantage from wildcard certs is less relevant.
Likewise, the wildcard leaf cert or the root/intermediate certs in your case aren’t likely to have much difference in risk for the same reasons if it’s all centralized, especially if you only provision for that single cert.
Try LetsEncrypt with Cloudflare, it’s fairly cheap to lease a domain annually and will likely be less of a headache for you 
You can still have your clients resolve DNS from your router for your setup, Cloudflare is only needs to manage the DNS challenge for LetsEncrypt with the domain you register.