One problem I see with this is - proxy IPs regularly get banned by third-party services by accident. So having multiple *external* IPs, and being able to switch between them, is a plus.

I think you're right that the proxies are a SPOF, but I see more controlled ways we could use to make them redundant, like having more than one of them per DC, and load-balance between them.

I think increasing the availability and resilience of this service is an excellent idea! However, adding more servers to per site feels like a requirement, and a standard Pybal/IPVS setup sounds much more appropriate than anycast for this use case.

More broadly: Pybal/IPVS and anycast have some overlap in the feature set that they provide to services, but given both how we use and have architected these two solutions, I think we should favor the former over the latter for the vast majority of the use cases and limit the anycast deployments only to special cases. Ideally these two offerings would eventually converge, but I feel like we're far from that right now.

+1 for improving HA of them and I agree that the LVS approach seems the saner one
If we don't plan to do this anytime soon though, maybe we could make an intermediate step with geodns.
We could have webproxy.discovery.wmnet resolving the local proxy by default but in case of maintenance or such we could depool one and have the clients use the proxy in another DC.