Sample release: http://musicbrainz.org/release/1d318c58-7f8b-4301-9d32-fa096878d2a1

For this release, MB shows cover art, but Picard claims "0 images".

I wanted to try forking Picard - unfortunately the barrier to entry is quite high, so I was unable to do any local tests.

The URL construction does seem slightly suspect - if I follow the code, I get "http://ec1.images-amazon.com:/images/P/B00G75IEEQ.02.LZZZZZZZ.jpg", which does not work; but without the extra ':' after the hostname, the URL does work (http://ec1.images-amazon.com/images/P/B00G75IEEQ.02.LZZZZZZZ.jpg).
Now maybe that's something the parse-via-QUrl-and-reconstruct stuff in CoverArtImage handles, but it did stick out.

However, the problem looks like it's more fundamental; the Amazon provider could use (a lot) more log.debug() calls, but it does have one that reports finding an ASIN - that message doesn't end up in the log:

D: 19:00:03 CA Providers order: Cover Art Archive > Amazon > Local > Whitelist > CaaReleaseGroup
D: 19:00:03 There are no images in the Cover Art Archive for 1d318c58-7f8b-4301-9d32-fa096878d2a1
D: 19:00:03 Skipping cover art provider Cover Art Archive ...
D: 19:00:03 Trying cover art provider Amazon ...
D: 19:00:03 Local disabled by user
D: 19:00:03 Skipping cover art provider Local ...
D: 19:00:03 Whitelist disabled by user
D: 19:00:03 Skipping cover art provider Whitelist ...
D: 19:00:03 There are no images in the Cover Art Archive for 1d318c58-7f8b-4301-9d32-fa096878d2a1
D: 19:00:03 Skipping cover art provider CaaReleaseGroup ...

So: it's not disabled (because enabled() would log that), but it's also not finding any ASINs. So either the URL relationship check (for 'amazon asin' or 'has_Amazon_ASIN') is faulty, or parse_amazon_url is failing (and it looks like it should not).