Emails are sent using the SMTP Protocol that originates in the early 80’s. Back in those days everyone connected to The Internet pretty much trusted each other, it was very much an academic / research network. Hence, thanks to these origins, the SMTP protocol provides virtualy no protection against the current threats - spam, phishing, viruses, identity theft, etc. Like with many other protocols from that era that still make the foundations of todays internet (DNS, HTTP, BGP, etc.) the authors of these protocols didn’t expect that anyone would try to abuse them and they didn’t build in any protections.
Therefore with plain SMTP I can send you an email appearing to come from your gmail addres, from president@whitehouse.gov or from any other address I choose. SMTP itself allows that, and SES uses SMTP. Of course because that’s the email protocol.
Indeed, that can easily be abused - that’s why over time some protections have been developed: DKIM, SPF, and others. However these are optional and depend on proper configuration both by the domain owner and at the recipient side. You would be surprised how many domains are completely unprotected.
So to wrap up - Amazon SES sends emails through SMTP protocol and like any other SMTP server can “impersonate” any sender address they like.
Obviously they won’t give you a completely free ride so before they send out any emails on your behalf you must prove that you control the sender address or domain. But that’s purely a policy imposed by Amazon, technically they could use any sender address if they wanted.
On the other hand: sending as something@gmail.com through SES may not be 100% reliable because gmail.com has SPF and DKIM configured and AWS SES can’t spoof these protections. But that’s on top of SMTP and it must be supported by the recipient too. If the recipient doesn’t check DKIM and SPF the email will get through.
Also - the sender IP address reputation matters. Any personal SMTP server will probably have a worse IP addr reputation than a massive, trusted service like SES.
All these factors contribute to spam score. If everything else (incl. the IP rep) says it’s not a spam a failed SPF check probably won’t tip it over. That's why your “technically invalid” email from SES gets through - because everything else but SPF seems to be OK. Spam assessment is a complex topic.
For the best results use your own domain as a sender and configure its SPF record to include / permit sending from SES servers.
Hope that explains it :)