The access token format in OAuth2 is an implementation details between the authorization server and resource server. At this time if you configure your own custom resource server (aka API) in Auth0 and want to leverage it to issue access tokens for that API then we impose the JWT format. In the future opaque tokens or other self-contained formats may be supported, but at this time it will be a JWT.
Having said that, no matter the format the resource server should validate that the access token was issued to it and not another API so the situation you mention about inability to pass the token to another downstream API is applicable independently of the access token format.
In relation to the
audience parameter it is not technically required so if you only have a single resource server for which you want access tokens to be issued you can configure it as the default audience in your account settings and in this way you would not have the need for any parameter that is not listed in OAuth2. However, the parameter actually brings additional flexibility and the specification itself kind of anticipates that because it makes possible for those additional parameters to be sent without forcing a compliant authorization server to reject the request.
In conclusion, you may either want to represent your micro-services as a single API or only require bearer token authorization at the entry point for requests coming from the outside; that is for service to service communication you would employ other means to validate that the request comes from a trusted party (for example, network level access).