Sorry for sending you down such a rabbit hole.
- Smallstep CA is an entirely different beast, that’s a full self-host CA service.
step-cliis just a command (single file) you can use like Caddy but offers functionality like creating and inspecting certificates.
I meant to show you roughly the equivalent process Caddy was handling for you to create a root CA + leaf cert and add the root CA into the trust store. I’m not sure how many actually read through my extra commentary like in the scripts shared (perhaps you chose to search more on the topic before seeing that, or I didn’t explain something well enough).
That was the intent of the added commentary and links to relevant docs for step-cli not Smallstep CA. There’s a lot on the topic you could learn about, but don’t really need to know about for the same reason you’d choose to delegate such responsibilities to Caddy. I tried to keep a balance with that.
You can see a compose.yaml example above. You could run that if it’s more comfortable due to the isolation. Likewise you can run the commands in a Dockerfile that extends that image, and inspect it with a tool like dive to see the actual changes made within a container when you do something like adding the root CA to a trust store.
It’s good that you want to understand before blindly running commands though 
Your question isn’t quite clear here.
When you want to use a wildcard certificate in Caddyfile and rely on local_certs / tls internal or the external ACME automation services, Caddy presently only supports the approach you’ve shown with the handle directive in a wildcard site block (as shown in the Caddy docs). There is a PR to provide an opt-in improvement where wildcard certs would be preferred, but it’s unclear when that’ll land.
Without the handle approach, if you have separate site blocks that will currently provision new certs for those site-addresses instead of using the wildcard.
If you use the tls /path/to/cert /path/to/key support instead for external cert management, then each site block using that can reference the wildcard cert and you can avoid the handle workaround.
However, for internal usage it shouldn’t matter too much. Your site blocks can just have Caddy provision their leaf certs via local_certs / tls internal and you’ll be fine.
- You only need the root CA cert in the trust store (for which all the leaf certs are derived from). The only downside here is you need each client / container to have awareness of this root CA cert, and ensure it’s updated before it would expire. This is usually why some self-host setups prefer to have a public domain for LetsEncrypt with DNS challenge, since the root CA trust maintenance is less hassle.
- The value of a wildcard leaf cert is often in privacy, when you use LetsEncrypt or similar services there are online sites that will keep a historic log that can be searched, which can reveal some insights of what services you have running if your subdomains reflect that. Other benefits are fairly minor usually.
If you had other concerns in mind with *.internal you’d need to clarify.