This is a problem in theory. In practice (and through experience) we see very little routing instability in the way you describe.
But although I would be surprised if load were not also part of the route picker, I would also be surprised if the routers didn't have some association or state tracking to actively ensure related packets get the same route.
But I guess this is saying exactly that, that it's relying on luck and happenstance.
It may be doing the job well enough that not enough people complain, but I wouldn't be proud of it myself.
An attacker could choose to only compromise devices located near a particular data center, but that would really reduce the amount of traffic they could generate, and also other data centers would stay online and serve requests from users in other places.
Most routers with multiple viable paths pass was too much traffic to do state tracking of individual flows. Most typically, the default metric is BGP path length, for a given prefix, send packets through the route that has the most specific prefix, if there's a tie, use the route that transits the fewest networks to get there, if there's still a tie, use the route that has been up the longest (which maybe counts as state tracking). Routing like this doesn't take into account any sort of load metric, although people managing the routers might do traffic engineering to try to avoid overloaded routes (but it's difficult to see what's overloaded a few hops beyond your own router).
For the most part, an anycast operation is going to work best if all sites can handle all the forseable load, because it's easy to move all the traffic, but it's not easy to only move some. Everything you can do to try to move some traffic is likely to either not be effective or move too much.