You are confusing the purpose of the openid scope. That scope is used to "enable" OIDC in an otherwise pure-OAuth server. By itself, the openid scope never gives you access to anything itself, so it should not impact the Access Token at all - which should not include that scope (as it would be useless anyway). The UserInfo endpoint should only return claims that were requested in the authorization request via scopes like `profile` and `email`. The ID token is only returned if your response_type includes `id_token` and usually means you want the claims directly returned as a JWT ID Token, and won't be making Userinfo requests.
For me, the "openid" scope gives me access to the UserInfo endpoint (which is provided by the Microsoft Graph API). So probably this is something where the implementation in Azure differs from the general protocol spec?
You can see it that way, but you need to understand that if what you want from the Userinfo endpoint is to obtain claims about the subject... and to do that, you need to require scopes that map to claims (the openid scope does not map any claim) or you need to explicitly request the claims directly. An authorization request that only requests the `openid` scope should result in a Userinfo response containing only the user's `sub` (because that's a mandatory claim to return) but the OIDC server may chose to just fail the request.