As I understand from this article: https://aws.amazon.com/fr/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/ :
This permits to extend the RBAC functionality.
Traditionaly, you create a Service Account and runs a Pod with this serviceAccount, so the Pod inherits the rights given to this service Account (via Role, RoleBinding, ClusterRole, ClusterRoleBinding). This is the responsability of the API server to check that the Pod can access K8s resources.
By extension, AWS adds the ability to bind authorizations to AWS objects (S3, etc) to a Service Account, by linking an IAM role (AWS native role) to a service account (K8S native role), using the iamserviceaccount object.
But this time, the API server is not able to check the rights of the pod for the AWS resources. The applications in the containers of the pod needs to get an IAM token to access the AWS objects. This token is placed in the service account, and is mountable in the Pod via a projected Service Account Token.
Finally, the service token account is some equivalent of a Secret, but instead of manually mounting the Secret to each Pod you want give access to, you place the token in the Service Account, which will be accessible to all Pods running with this service account.