All sorts of things can lead people to erroneously assume that an email is spam (and mark it as such).
For example, if your app sends out an automated email that isn't clear about what site/service it relates to, a proportion of recipients are likely to mark it as spam without reading it and figuring out who its from. Few people have time to read email that looks to them like spam.
Or, if your company or service emails its list of subscribers for the first time in months, quite likely half the list will have forgotten who you are and the fact that they opted in to your list in the first place. And a disproportionate number of them will mark your email as spam.
Or if people sign up for MyBrandedWebsite.com, but then receive an email from Software Company X (the company behind MyBrandedWebsite.com), people won't recognize the link, and a proportion will mark the email as spam. It's a rookie mistake on the part of Software Company X, but it happens all the time.
Ultimately, minimizing spam reports requires a lot more than double opt in and an unsubscribe link.
Amazon will be keen to minimize spam reports for emails sent through their system, because they'll need to ensure that their deliverability rates stay high. So they'll need good automated systems to detect spammers. But email/spam detection is an inherently fuzzy business, and false positives are inevitable. If a false positive could bring down an entire service hosted on AWS, even if just for a few hours, then using SES starts to look pretty risky.