I did a quick test and could not reproduce this situation when using the sets of scopes you mentioned. For the behavior you describe the most likely cause is that the access token in question was issued as part of an authentication transaction where the only OpenID Connect scope requested was the openidone. Asking only for the openid scope will indeed result in the user information response containing only the sub claim (assuming the request is run as part of OIDC compliant mode and/or is an API Authorization request).
You included a line referring to the scopes you intend to request, but there’s likely something going on either at the client application level or through a rule that is resulting in the additional scopes profile email not being requested and/or granted.
I would recommend you to use the browser networking tools to inspect the requests performed from your application to Auth0; this will allow you to confirm if the scope that the application is actually requesting is the one you expect. In addition, ensure that you do not have any enabled rules that could affect the issued access token by overriding the issued scopes using context.accessToken.scope.