Based on the information provided I get the impression that you’re starting the implementation of a new application or at least significantly changing an old one so my recommendation would be for you to not take a dependency on that ID token ability to call management API for very specific user operations.
You can request an access token for Management API if you specify the respective audience; it’s likely that you already are specifying an audience value so you may need to perform a second authorization request specific to the Management API; this authorization request can request a scope like update:current_user_metadata which would then allow you to update the user metadata from the client-side. Have in mind that by default an authorization request for the Management API as part of an end-user flow will trigger the consent screen so if you want to bypass that you’ll need to enable the Allow Skipping User Consent in the Management API settings. Skipping consent could mean that the second authorization request could even be done in the background and leverage the existing session so that this is transparent for the end-user.
With regards to always having to pass the user identifier it’s an implementation choice, it could be argued that if the token is always associated to an end-user that could be optional, but it does not seem to be a big issue.