Though doing this "well" is subjective, so I can understand someone preferring Tailscale because it's easier to use.
if your access concentrator (server) is behind a nat, you'll need a port-forwarding from the outside but that's rare.
For example, you can set ACL rules for which devices can access which others (or the internet, if you have explicit exit nodes) - it's using Wireguard for networking, but you can't do that with (just) Wireguard, it's not just 'make Wireguard easier to set up', as you said that doesn't really need doing.
There's value to some to having networking config centralised like that. It allows things like auto adding certain clients to certain rules/groups automatically.
Not spending time cycling through each server to poke iptables.
This is just irrational. The client is open source. You can build it and run it from source.
The sentence following the one about phoning home/leaking data explains the rationale. The computer user prefers simpler software. It's great that it's possible to compile a client from source, but this does not address the complexity issue.^1
Is the Tailscale control server open source. Why not. What's the rationale for that.
There's no problem IMHO with arguing Tailscale can make its own decisions and do whatever it wants. However the same argument must apply to the computer user. He can make his own decisions and do whatever he wants.
1. Wireguard was allegedly written at least in part because OpenVPN, another open source option, was excessively complex. Tailscale relies on Wireguard. If avoiding complexity was irrational, and people behaved rationally, then perhaps Wireguard would not have been written and Tailscale would not exist.
Avoiding complexity where possible sounds rational to me.
The official reason for why there's no official open source server is that headscale got there first, before tailscale team could (their words, not mine) the unholy mess that was the production server into something people could compile and deploy themselves.
Even so, software being open source doesn't make it inherently trustworthy. I would have to look into it, or trust that the community has done due diligence. My default stance towards all software is to not trust it, which can change as I get familiar with the project.
And then there's the complexity. I prefer using simpler tools if they accomplish what I need. It's less surface area for me to trust, and less chances for bugs. Not that Wireguard is necessarily simple, but since Tailscale is a wrapper around it with additional features, none of which I need, I'm perfectly fine using WG directly.
Something I don’t understand is if the client is open source, why is it not in the fedora repos? Why do I need to add a new repo to dnf?
Just because one group of people haven't done something doesn't mean it doesn't qualify. To show the exact opposite, look at OpenBSD. They have included Wireguard into their kernel.
Fedora not including Wireguard may be political, personal, or none-of-the-above. Maybe somebody hasn't offered to take on that task/responsibility.
The master config is essentially the Fabric script. It contains each servers IP, public key, etc. We even do server-server pre-shared keys.
Besides, Wireguard alone already does all I need from a mesh VPN. The UX could be a bit better, but I wouldn't trade ease of use for the peace of mind that my VPN traffic is secure.