Q:

How does anycast ensure reliable delivery of IP packets for the same IP address on different locations?

With anycast, it would be possible to have the same IP address at multiple locations in the world, without the need of a proxy or VPN that forwards the packets to its final destination.
If you would just use IP spoofing to change the source IP address to for example  6.7.8.9, normally you would not be able to just receive the response packets for this IP address, as the Border Gateway Protocol determines a different path back for the response packet that you normally won't be able to intercept.
What does anycast do so you can reliably receive IP packets meant for this particular IP address? Since the shortest paths BGP relies on can change, which mechanism ensures that when you send a request at location A that has IP address 6.7.8.9, you will receive the entire response back to location A and you won't receive a response with also a few packets delivered at location B that has IP address 6.7.8.9 and another few packets delivered at location C that also has IP address 6.7.8.9?
For DNS it might not matter, but Anycast is also used by CloudFlare for the content delivery network, which would be HTTP(S) over TCP and not just UDP Packets.
Edit:
How about this scenario: Server A and B have the same IP address with anycast. Server B connects to an external server that is very close to server A and very far away from server B, since server A is closer, the response will be routed back to server A, isn't it possible to always route this type of requests back to server B, since server B initiated the connection to the external server? 

A:

...which mechanism ensures that when you send a request at location A
  that has IP address 6.7.8.9, you won't receive a response with also a
  few packets delivered at location B that has IP address 6.7.8.9 and
  another few packets delivered at location C that also has IP address
  6.7.8.9?

That's really the point of anycast. When you send something to an anycast IP address, the routing protocol will route the traffic to the nearest (according to the routing protocol) network for that address. If there is a problem where a link to one of the networks goes down, the traffic will automatically be rerouted to the next nearest site. You, as the sender, don't care which one gets the traffic. That's why it is so useful for things like DNS and NTP.
It's not like an individual can just start advertising a network on the public Internet. Someone advertising a network on the public Internet better own that network. If you have a BGP relationship with ISP(s), they will find out if you are advertising a network you don't own, and you will be summarily cut off from BGP peering with the ISP(s).

Anycast is also used by CloudFlare for the content delivery network,
  which would be HTTP(S) over TCP and not just UDP Packets. If you are
  in middle of uploading some data and the data get scattered over
  different servers, would the only option be retransmitting it and
  hoping it goes to the right server next time or does anycast have an
  option to prevent this?

TCP cannot get scattered over different servers. TCP is a connection-oriented protocol, and it creates a connection. If a link to a server to which you have a connection goes down, you would need to create a new connection to the next server in line. Anycast is nothing more than using the routing protocol to get the traffic to the nearest network with that network address.

If anycast is used and if the path to server A is the shortest path
  for one fraction of a second and then the path to server B is the
  shortest path for another fraction of a second and then the path to A
  is the shortest again for another fraction of a second, etc. it would
  get scattered over different servers. It takes several seconds before
  it goes to the timeout state and TCP would require several
  retransmissions attempts to be made before it goes to timeout.

That would be a serious network problem if the routing changes that often, especially on the Internet. BGP will notice flapping, and it will penalize the flapping link, and the link will get dropped from routing updates. You would be hard-pressed to find what you fear in the real world. ISPs take stability very seriously, and they will block partnerships which display instability.

How about this scenario: Server A and B have the same IP address with
  anycast. Server B connects to an external server that is very close to
  server A and very far away from server B, since server A is closer,
  the response will be routed back to server A, isn't it possible to
  always route this type of requests back to server B, since server B
  initiated the connection to the external server?

You are really trying to make this a lot more complicated than it is. You don't initiate a connection from an anycast address to any old address on the Internet. Anycast addresses are destination addresses. If a host with an anycast address needs to contact a different host on the Internet, it uses a non-anycast address, either with a secondary address on the interface, or, more likely, a different interface. Don't confuse the anycast address with the host itself.

Seriously, there are some very, very smart people who do nothing all day but think about this sort of thing. RFCs must be peer approved before they are released as proposed. If nobody has any real objections, they are promoted to RFCs. The whole world has these under a microscope from the very inception of the idea, through, and after the release of the RFCs. If there really was a flaw in anycast, it would have been discovered, and solutions proposed, years ago.
There are multiple RFCs for anycast: RFC 1546, Host Anycasting Service (November 1993), RFC 4786, Operation of Anycast Services (December 2006), and RFC 7094 , Architectural Considerations of IP Anycast (January 2014). These RFCs will explain how Anycast works.

