I think you answered your own argument: "If it's faster for you, switch mirror."
The point is that users should not have to care about switching mirrors, and (with somewhat
less importance) administrators should not have to care about setting up mirrors and fixing
the various things that can go wrong with them. Bittorrent is a more complex protocol, but it
is often simpler to use and maintain. Let the computer do the hard work of figuring out which
site is the nearest and which site has which data.
(I have two Fedora machines on my local network; I could spend disk space and bandwidth
setting up a full mirror but it would be a hassle and download more than I need. An
alternative is to set up a caching http proxy - but if Bittorrent were used, the machines
would just share the downloaded data automatically.)
It need not necessarily use uplink capacity for the end users. A leeching Bittorrent client
would be fine for downloading package updates. I proposed setting up Bittorrent servers
instead of traditional mirror sites - such a server would be a regular Bittorrent node
configured to participate in the package torrents. Since the server is just there to provide
speeded-up downloads to the users, it can run in generous mode where it will happily provide
data to leeching clients.
Distribution of torrent metadata is indeed a single point of failure. But so is distributing
a list of mirror sites. Whatever update method you use, you must start with a single point