Providing a bit of history on the subject for the purposes of setting up the context. The restrictions on searching over user metadata custom fields was put in place as part of an incident response; the short summary is that the restrictions were needed to ensure stability of the user search functionality. Having said that we understand that existing accounts before the incident may already had a dependency on that functionality and as such we try to accommodate the requests to re-enable the search without restriction from those pre-existing customers as long as the use case is reasonable; see the email address listed in the linked incident that you can use to report such a situation.
In addition, the user metadata still has a valid use case even without the search, in particular, it allows you to associate data to the user profile in way that it can be used to make authentication/authorization decisions during the authentication flow. For example, user metadata is surfaced to rules where you can then perform custom logic to deny a particular authentication request without the overhead of querying information from an external system. However, like you mentioned the user search allowed for some use cases in user management back-end systems that are not available without the unrestricted search. We acknowledge this situation and we want consider and possibly enable these use cases in the future, however, we will want to do it in a way that reduces the likelihood of a similar outcome so at this point there is not yet definitive information about what will be available.
For your particular situation if the data you were storing in association with the user is related to authentication and authorization decisions then it seems a valid use case for metadata (a subscription status that can be used to reject authentication would be an example, but see the following for reference documentation on the topic: https://auth0.com/docs/user-profile/user-data-storage) and I would consider reaching out to the email mentioned before as you already designed your application around that expectation. If you were storing general business data as part of user metadata then my recommendation would be to consider a separate data store.