I would say it really comes down to the use case. If you're already using TLS and have the infrastructure for key management, issuing certs, etc. It's not worth replacing.
To me, where WireGuard comes in is for services that aren't traditionally encrypted, or where an extra layer of security is desired.
The example case that we've seen a few times is cluster DNS. The DNS traffic internal to the cluster is just plain DNS, meaning it leaks internal information and can be tampered with on an untrusted network. Even though CoreDNS does support DNS over TLS, it's a large effort to update clients in some organizations, that is better spent elsewhere.
This is where we see the opportunity for WireGuard, is ensuring all internal traffic is encrypted. For taking applications where the security model traditionally requires a secure network, and allowing them to be forklifted into a kubernetes cluster that provides those capabilities. I'm not saying this is an ideal model over using mTLS for every connection, just not everyone has what's needed to deliver mTLS everywhere.
Unfortunately, we do lose the identity features that TLS offers in the x509 certs. Nothing prevents running TLS for services that need it though on top of the WireGuard network.
So like everything else, I think there are pros and cons to both approaches, and it depends on what applies to the specific application.
I'm enthusiastic about WireGuard but I'm dubious about the "forklift" approach you describe. Actually, more seriously, I doubt in most cases that systems to be forklifted were truly secure originally and so while I don't think using WireGuard makes that worse, it may mean an opportunity is missed to fix more serious problems.
Presuming that by mTLS you mean mutually authenticated TLS, I don't see it as a good fit for internal systems - to me (as someone who has implemented mutual auth to considerable success) it's best where you have B2B applications, because you've got the three distinct parties that make a PKI worthwhile. Whenever I see a PKI in which all three of the parties are essentially identical I cringe, e.g. I keep seeing OpenVPN setups where one person runs the CA, runs the VPN server and mints all the private keys - the PKI is pure theatre in this approach, it makes no difference to anything.
To me, where WireGuard comes in is for services that aren't traditionally encrypted, or where an extra layer of security is desired.
The example case that we've seen a few times is cluster DNS. The DNS traffic internal to the cluster is just plain DNS, meaning it leaks internal information and can be tampered with on an untrusted network. Even though CoreDNS does support DNS over TLS, it's a large effort to update clients in some organizations, that is better spent elsewhere.
This is where we see the opportunity for WireGuard, is ensuring all internal traffic is encrypted. For taking applications where the security model traditionally requires a secure network, and allowing them to be forklifted into a kubernetes cluster that provides those capabilities. I'm not saying this is an ideal model over using mTLS for every connection, just not everyone has what's needed to deliver mTLS everywhere.
Unfortunately, we do lose the identity features that TLS offers in the x509 certs. Nothing prevents running TLS for services that need it though on top of the WireGuard network.
So like everything else, I think there are pros and cons to both approaches, and it depends on what applies to the specific application.
I hope that helps.