Hi @michi, nice diagrams! 
I'll just start off that this sort of functionality has been discussed for many, many years now. We've dabbled in soliving it here and there but in practicality the deman for us just hasn't been substantial enough yet for us to implement. There are some real benefits that TCP has over UDP but it's on our roadmap to implement. In general, we want to be able to do both eventually.
This will always be use-case driven but if you're going from one remote location to another, you'd be surprised at how little difference this ends up making in practice. That aside tho, Tailscale still offers a TURN server so it's quite possible your wireguard traffic might route through a Tailscale TURN server if UDP hole punching doesn't work (it's not always allowed). Blocking UDP traffic like this is a common source of frustration for some wireguard users (from my own reading).
Again, it'll be use-case dominated but in my own testing this has not been true (anecdotal maybe). I'm sure there are cases where it WILL be true but practically I just haven't had a problem so far. This just goes to the "demand hasn't been there yet" comment I made before.
I hate saying it but this is another one of those "you'd be shocked at just how non-intensive this actually is" imo. If you're doing 100's or 1000's of these, well then sure you might end up saturating CPU or the network itself or some other resource. For smaller-medium scale, I don't think that'd be all that noticable.
So that's a few reasons why it's not implemented yet. TCP (TLS) also allows us to implement mTLS, we can dial outbound ONLY and never have inbound holes so it works when UDP hole punching won't (the TURN server idea), and there's probably other benefits that I'm not thinking of...
Hope that helps?