Why are there always at least two authoritative name servers for a registered domain?

I see that almost all registered domains have at least two authoritative name servers configured (and for most of them, exactly two), and that using two servers provides redundancy against any kind of server failure. Technically there's no restriction on number of auth NS servers, so a single NS also works.

However, for some zones, there are already multiple addresses for one server configured, like ns1.qq.com (4 IPv4 addresses, auth NS for qq.com.). And for some other zones, the name servers are distributed using techniques like anycast, like ns3.cloudflare.com (one anycast IPv4 and one anycast IPv6).

In those cases, why would one still configure multiple authoritative name servers for a zone, when one NS entry can already provide redundancy against physical server failure?

In the early days of internet, registrars required you to have two DNS servers at different physical locations before they would register your domain. I don't know what today's requirements are, but I'm sure that historical tradition has carried on past the point where it was strictly necessary to provide redundancy. And a lot of the ones you see are probably the original NS pairs that were registered, and it just never changed.

It's also much simpler to do it that way than to set up anycast, hot failovers, etc.

First off, the title asks "why are there multiple authoritative nameservers?", while the question body clearly assumes that "of course there will have to be multiple authoritative name servers for redundancy" (indeed the answer to the question posed by the title), and instead asks "why are there multiple NS records?".
With this in mind, I consider the question posed by the title to have been largely answered already in the question itself. Redundancy is desirable, one does not want to rely entirely on a single host or a single network.

Traditionally, the NS records were simply pointing to different hosts that were acting as name servers, and with that as the starting point it makes sense to simply add NS records for each host that is authoritative for this zone.
This in turn led to some default behaviors that assumes that each name represents a host rather than any arbitrary grouping of hosts, like the notify behavior suggested in the spec is to send notifications to the NS hosts except SOA MNAME (ie, notify all nameservers except what SOA identifies as the master).

Now, the remaining part of the question splits into examples of two cases:

• Multiple addresses (of each type, like multiple A / multiple AAAA) for a single NS name that could then represent multiple authoritative servers providing redundancy:
  This can certainly be done, but to me the use suggested by the question just seems like a less conventional way of doing the exact same thing that the question criticizes. The advantage is unclear and it breaks expectations and thereby might cause unexpected issues (like maybe your registrar does not allow you to provide any number of glue records for a single host, or whatever).
  In the actual example mentioned in the question they have four such NS records all with multiple addresses, so they are doing both things at the same time. With their large number of addresses maybe there might be an advantage to this approach, but that seems like an edge case beyond what the question is truly going for.

• Anycast for redundancy:
  This might be the stronger argument in one way, where a single address (per type, like single A / single AAAA) can represent multiple authoritative servers. However, the way anycast is BGP-based, first of all, it's not available to just any name server operator so that makes it hard to argue that everyone could/should just do it this way, but more importantly with just a single address it still creates a big dependency on one specific route advertised in BGP "working right". Ideally one will still want multiple addresses in different networks.