A domain name simply is a pointer to an IP address (oversimplification, it does other things as well, but that’s the case in this context). So technically there is an IP address, it’s just fetched by using a DNS resolver.
It’s not “already proxied”, but I’m not sure what your line of thinking was to get there so I’m not sure what to say.
Correct, that’s a TLD that OP decided to use, but you could use any custom TLD you want as long as you have a DNS server in your home network to make it work.
No, not at all. I think the key point you’re missing is that this wiki article specifically aims to explain how to set up TLS between internal Caddy servers.
Most users don’t need this, it’s just one approach to setting up a network in a “paranoid” way, where all traffic is encrypted all the way to the app.
See Using Caddy as a reverse proxy in a home network for comparison, where the most common goal is simply to ensure traffic is encrypted over public networks, and once it’s inside of the home network it doesn’t matter as much so proxying can happen over HTTP (cleartext). Also, make sure to re-read the introduction of OP’s post, it explains that distinction.
You can certainly just use a single Caddy server and proxy directly to your apps in your home network. That’s the easiest thing to do, and totally sufficient, when you trust all the devices in your network.
The gap that this article closes is: if you have some untrusted device in the home network, then it could theoretically sniff traffic between internal Caddy servers (the front and back ones) and potentially perform a man-in-the-middle attack, injecting bad data or stealing data. But the risk of that is very low because it requires first having gained access to your network, in which case it’s already game-over anyway.
Yes, for sure. But I’m not sure if you’re asking about the multi-server setup or just “does Caddy work in Docker at all”. Either way, yes. Some things become simpler, some become more complicated when in Docker, but that’s fine.