So aside from aws-cli skipping over newer files in destination, I think their behavior is identical.
aws-cli (after a quick perusal of their source code) uses the LastModified value (set by S3 to be the time the upload of the object occurred) on objects in S3, which is obtainable from the <ListBucket> XML, without doing a HEAD call. They then go on to calculate the difference between LastModified and stat.mtime(), accounting for time zone differences. local files use stat.mtime.
aws-cli then proceeds to compare the two values; if LastModified is newer than stat.mtime, syncing local->remote is skipped (the remote is newer than local); likewise on download, if LastModified is older than the local file, it too is skipped.
Neither tool sets LastModified = stat.mtime on upload (nor can they). s3cmd gets around this by setting stat.mtime into the file's metadata when --preserve (the default) is used, but then would have to use a HEAD or GET call to get it back. s3cmd does update the local on-disk mtime and atime when downloading (GETting), because we get the header back, and that's free then. Likewise, aws-cli sets both mtime and atime = LastModified on download.