I'm assuming that your API provides functionality and/or resources that are associated or owned by an end-user, and you want to allow other application to also access this data on behalf of each end-user. If this isn't the case, and you API is general-purpose and does not require the notion of an end-user identity then other approaches like API keys could also meet your requirements.
Considering the end-user delegation scenario, the approach I would recommend would be going with the creation of separate client applications within Auth0. Like you said, you could automate this process through the Management API so that this process could be handled in a self-service way. Despite being self-service, the application that enabled the registration could still apply constraints in order to make sure only eligible developers could obtain the necessary information to then obtain access tokens to access the API.
This has the benefit that if you wanted to stop an existing developer from using your API you could just remove the associated client application and they wouldn't be allowed to request access tokens anymore and the ones they already had would be short lived and soon expire. This requirement is more complex to implement when using long-lived tokens because they would need to be revoked/blacklisted.
A final note, if these applications don't require to act on behalf an end-user when calling your API and you would prefer to still accept access tokens instead of using a different approach like API keys, then you can consider registering client applications meant to use the client credentials grant.
