To assume a role with OIDC you'd need to do it from the context of a specific CircleCI job run - getting access to the secrets of a particular CircleCI account alone would not be enough to authenticate to AWS (unlike when you use IAM user credentials).
Even if the attacker had access to env vars from running jobs (which includes the signed token needed to do an OIDC role assumption), those tokens have a short expiry time, and even if an attacker stole that token and performed a role assumption then that session can only be valid for a maximum of 12 hours in AWS, and then you know the attacker is out of your account.
It just significantly reduces, practically nullifies, anything that an attacker can do in your AWS account.
I assume what they meant is having AWS accept short-lived OIDC tokens from Circle's OIDC provider, which in turn would generate them on demand when the CI is actually run. There'd be no secrets at rest and the attack surface would be (in principle) smaller.
Even if the attacker had access to env vars from running jobs (which includes the signed token needed to do an OIDC role assumption), those tokens have a short expiry time, and even if an attacker stole that token and performed a role assumption then that session can only be valid for a maximum of 12 hours in AWS, and then you know the attacker is out of your account.
It just significantly reduces, practically nullifies, anything that an attacker can do in your AWS account.