The access token format is an implementation detail between the authorization server (in this case your Auth0 account) and the resource server. This means that different formats can be used as long as both of the intervening parties agree with the format and support it.
Also have in mind that even though an additional actor (the client application) receives this access token, the client application should treat it as an opaque value and make no assumptions about the format. In this case, given you received a non-JWT access token it likely implies that you only requested an access token that allows you to get user information about the authenticated user.
In this scenario the resource server is the Auth0 user information endpoint and one of the formats supported by that endpoint is a short opaque access token.
If you want to receive a JWT token that contains within itself information about the end-user then you need to perform a request following the OpenID Connect (OIDC) specification an include a response type that also requests an ID token and in addition include the
openid scope. An ID token will always use the JWT format because the OIDC specification mandates it. In addition, an ID token can be parsed and processed directly by the client application.
If you want to receive an access token that can be used to authorize calls to resource servers (aka API’s) that you implement yourself then you need to include the audience parameter for the respective API as part of the request. Currently, for a request with an audience associated with your own API, a JWT access token will be issued because that will allow your API to validate the token without additional calls. See API Authorization for more on this subject.