SQS/SNS/S3 are so simple, reliable, and cheap they're pretty much a no brainer. While you can probably run those workloads in Postgres, it isn't designed for those use cases and you'll eventually run into nasty limitations like managing vacuums with high churn tables and slow/complicated backups with big binary blobs.
If you have a good understanding of load up front, however, those are probably non-issues.
I know, I'm mostly being tongue in cheek - the joke is so many companies go straight to complex cloud configurations more for the vibes than the actual practical need; a single box (two for availability) and a solid db will get most sites and businesses very far.
You might not technically need it but some of the things offered by those services might be ‘nice to have’ for your specific use case. If they are not available with just Posgres+etc out of the box the few hundred/thousand $ additional costs might be entirely insignificant compared to the additional work-hours you’d need to implement those things.
If you have a good understanding of load up front, however, those are probably non-issues.