I think the reason those resources state is because strictly speaking it negates the purpose of access tokens, on which existence OpenID was built upon. After all, ID tokens are intended exclusively for the client.
I have seen your approach before; the access tokens issued by Microsoft Teams on behalf of third party apps are just ID tokens provided with an additional scope claim. There are essentially treated interchangeably by design.
Since an ID token is guaranteed to be signed OpenID,
ID Tokens MUST be signed using JWS [JWS]
I see no issue regarding validating the authenticity of the token. You also mentioned the lifetime being configurable which allows to lower the lifetime accordingly if necessary. Yet, here are a few things to be considered (please note that this list might be incomplete):
The ID token's recipient is the client, while the access token is issued towards the resource server. I am not familiar with how AWS handles this but this might cause issues upon validation as the client id is usually different.
For public client there are little to no options to encrypt ID tokens as the recipient can't store the corresponding secret. However, you can encrypt access tokens as they are usually merely used as Bearer tokens without valisation through the client. If you happen to use the ID token as both you lose that option (provided AWS even grants this).
Sender-constraints (the possible killer)
There are additional mechanisms for client authentication such as Mutual-TLS or DPoP which are effectively based on the client possessing a secret to add additional authentication when passing the access token. Identity providers might not support this for ID tokens. I am not aware of this working for public clients anyway but am adding it for the sake of thoroughness.