The drawback when there's replication come from the note below:
Amazon S3 routes any virtual hosted–style requests to the US East
(N. Virginia) region by default if you use the US East (N. Virginia)
endpoint (s3.amazonaws.com), instead of the region-specific endpoint
(for example, s3-eu-west-1.amazonaws.com).
When you use replication you usualy let AWS takes care of routing the alias to one region by targetting
s3.amazonaws.com in your REST request from your servers and let the redirect do it's job.
Whenever N.Virginia is down, the magic cease to work and you're out of luck to access your data and have to update your configuration to choose a specific region endpoint.
The problem does not come from the DNS (a request to the bucket itself will work) but from S3 clients, which will connect to the S3 API endpoint before accessing the bucket, in this case the dns resolution is done on
s3.amazonaws.com and this is us-east-1 endpoint.
When you use regions alias, you loose the ease of load balancing over regions with the health check from AWS included.
If you use DNS cname targeting the regions to switch quickly, you're responsible of your DNS TTL but nothing guarantee cache servers of client ISP will honor your value (one of many cache your client may encounter).
And lastly, if you try to load balance yourself you'll probably create the same SPOF than AWS already have with the added burden of maintaining it.
AWS is working on it but that's all the information I have at time of writing.