Addressing the points you raised:
1) We are obliged to retain our copy of files uploaded for storage on our server indefinitely as long as the merchant keeps their subscription active.
For remotely-hosted files, we can delete any file copies from our cache at any time (most likely for small or rarely-downloaded files) as needed to optimize our storage use, as we expect to be able to restream the original file from its remote URL at any time, and caching a copy to serve up for future downloads also minimizes both your and our transfer bandwidth usage and costs while generally maximizing performance for the downloader via S3's high-performance service, which brings up your next point:
2) I tested the same Free Download links you'd generated for your own tests, and found I was getting nearly 200kBps from Amazon S3, saturating the 1.5Mbps pipe we've got to the office here. Did you wait at least 15 minutes after completing the first download attempt for the same product before testing again?
When you click your download link, an Open/Save dialog should appear (at least in Firefox) showing you where the file is coming from. If the file's already been synched up to S3 by then, that dialog should show the file's origin as s3.amazonaws.com; if the sync hasn't completed yet, then it would be showing as [somehost].e-junkie.com, in which case throttling would be involved to prevent saturating all of our available datacenter bandwidth and maintain high availability of our service for all users.
I'll ask our Lead Developer to check if there might be anything unusual going on at our end (or Amazon's end) at the moment causing download congestion from S3 in particular. You might also ask your ISP if they know of any congestion or other transient routing issues between them and Amazon S3 today. As I reckon you're aware, no Internet connection is a direct, point-to-point route; the routing between your ISP and your hosting may be far simpler and less congested than the route between your ISP and Amazon S3. You might try running a traceroute both to your host and to s3.amazonaws.com, to see if you can identify a clear delay along the S3 route somewhere upstream from you.