The problem with Anycast is it works pretty good for UDP (such as DNS) but doing Anycast with your actual TCP connection (particularly long lived ones) can be problematic because of shifting routes, multipath, etc.. meaning that sometimes your traffic will change data-center mid-flow or possibly even with alternating packets in the case of multipath somewhere etc. So suddenly your HTTP connection data is arriving at the wrong data center and the connection breaks.
What most providers currently do (as far as I understand anyway, I'm sure there is a lot of hyper optimization) is based around using Anycast to receive the DNS lookup, and use information from that DNS lookup to send back a relevant POP locations IP.
That's not always based purely on which DC received the DNS request though, that's the most naive implementation, but most of the big CDNs optimise the returned server based on the source IP of the lookup among many other factors.
Hence why it matters for public DNS, since they are the source of the DNS request.
This article however also discussed that Anycast doesn't always route traffic where you would "expect", for various reasons that extend from commercial agreements and cost all the way to bad configuration and "no idea" you may not get routed to the nearest DC.
There is also a DNS extension, called "EDNS0" (also discussed in the article) that sends the /24 of the IPv4 IP along with the query, to allow the DNS resolver to customize their response particularly for these centralized DNS services (e.g. Google DNS supports this but only if you apply to receive them as an authoritative DNS server) - however APNIC/CloudFlare explicitly chose not to use this I believe supposedly for privacy reasons with 1.1.1.1.