Holding OIDC's narrative up to the light

OpenID Connect's (OIDC) stated aim is to provide the authentication neglected by OAuth. Yet I find some of its specification hard to reconcile with that narrative. For example, here are two of the claims OIDC standardises for the ID token. Their description puzzle me, especially when placed side by side:

aud

REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. …

azp

OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. …

The Relying Party (RP) is the application that needs the user's identity information and hence takes the initiative for the OIDC dance. That means that it is also the entity that will receive the ID Token, in other words the authorized party, which leads me to conclude that, if the azp claim is present, it will contain the client ID, A.K.A. client_id and Client ID.
Taking the spec literally, therefore, the azp claim should never be needed since, if the ID Token has a single audience, it must contain the azp. We can only assume that this is not the intention of the spec.
Moving beyond this apparent inconsistency, what could motivate the inclusion of these claims in the ID Token? I do not see any use for them in an identity and authentication context. My birthday, for example, does not change depending on who is asking. For authorization, on the other hand aud and azp are very useful, even indispensable.
To see this, let us discuss a simple case where the authorization server is in a position to take a definitive authorization decision for all resources located at endpoints https://<host>/foo and htps://<host>/bar. When /foo receives a request, it knows that it can grant access provided the request is accompanied by a valid token. The notion of validity must include that the target audience of the token is /foo. If /foo does not check this, attackers can gain unauthorized access to /foo by obtaining an access token for /bar.