Anycast is essentially an SPOF. Well, not only anycast and not anycast per se, but a single AS it is under. It breaks from time to time because of various mistakes, bugs, etc. and brings down every server as a consequence. This occurs roughly every couple of years and takes hours to resolve.
So, with anycast, if you have 10 servers in different places, you get hours of downtime for 100% of users from time to time.
With DNS, on the other hand, if one server goes down, it affects only 1% or so of users of a particular server, that have incorrect TTL in the resolvers they use, others see change in DNS right away and use working server. But, those 1% of users don't all go to that server at the same time, only small percentage of them does and also sees the old record. Leaving us with let's say 10% of that 1% on 1 out of 10 servers, or 0.01% of all users unable to see the new DNS record for an hour or so. If a typical server on some random AS goes down five times a year, you get 0.01% * 5 * 10 or 0.5% of users affected for an hour per year. Now if you use round robin and let users see multiple records nothing is even going to stop working in the browser for them, just going to make them wait longer until they see a set of working records.
To summarize, anycast is 100% of users not able to reach any server for hours every couple of years, while DNS is 0.5% of users experiencing slowness for an hour per year. In other words: anycast alone cannot be reliable enough for a CDN.
You have to understand that anycast comes from ISP/networking people, who are biased towards network level solutions for anything and don't care about hard numbers, no matter how badly anycast looks there.
EDIT: Anyway, resilience, just like security, needs a threat model to avoid wasting resources on things that don't actually work, otherwise it's all just hype.
As someone who has looked into deploying a DNS based CDN, I have frequently found ISPs ignoring TTL.
Routers handle bgp updates much faster. Anycast routing is much more superior to geolocation which gives a completely incorrect location as high as 10% of the time. Anycast ips are also the best way to handle DDoS attacks. Attackers can easily shut down ips listed in DNS while people's ISP and browser repeatedly try to access the same dead IP for hours.
If DNS was an acceptable option, I would have gone with that instead of paying a CDN for an anycast solution.
These are all from my personal observations, they are not something I just heard from "ISP/networking people".
Anycast is essentially an SPOF. Well, not only anycast and not anycast per se, but a single AS it is under. It breaks from time to time because of various mistakes, bugs, etc. and brings down every server as a consequence. This occurs roughly every couple of years and takes hours to resolve.
So, with anycast, if you have 10 servers in different places, you get hours of downtime for 100% of users from time to time.
With DNS, on the other hand, if one server goes down, it affects only 1% or so of users of a particular server, that have incorrect TTL in the resolvers they use, others see change in DNS right away and use working server. But, those 1% of users don't all go to that server at the same time, only small percentage of them does and also sees the old record. Leaving us with let's say 10% of that 1% on 1 out of 10 servers, or 0.01% of all users unable to see the new DNS record for an hour or so. If a typical server on some random AS goes down five times a year, you get 0.01% * 5 * 10 or 0.5% of users affected for an hour per year. Now if you use round robin and let users see multiple records nothing is even going to stop working in the browser for them, just going to make them wait longer until they see a set of working records.
To summarize, anycast is 100% of users not able to reach any server for hours every couple of years, while DNS is 0.5% of users experiencing slowness for an hour per year. In other words: anycast alone cannot be reliable enough for a CDN.