It is a known issue that the metatag module combined with tokens causes considerable performance overhead, which gets worse with any additional token that is used. See https://www.drupal.org/project/metatag/issues/3039650 as for more information and recommendations on how to improve that situation a bit.
Memory usage
That however is not the focus of this article. Instead, what I've noticed a few months ago when profiling a client project with Blackfire is that it's not just time-consuming but also used a lot of memory too. Digging deeper, I tracked this down to the _token_module function. This function is used to check if a certain token type should be handled by the generic field token implementation of the token module.
The problem is that it has to load the full token info to do that, and that information grows with every content entity type and field that a site has. On our sites, we typically saw memory usage of that method between 5MB to 8MB but it on sites with a very large amount of fields, it could also be considerable more than that.
To improve this, the cache collector pattern was implemented to store only the information which stores only which module provides a given token type, and only for the token types that are actively being used, gradually building up this information, typically on the first few requests after a cache clear. Afterwards, the overhead of this function is so small that it is no longer visible in profile requests.
We tested this on our projects, and then it was committed in https://www.drupal.org/project/token/issues/3440371 and released as part of token 8.x-1.14.
Positive impact on garbage collection
Beside improving memory usage, we also saw a positive impact of this as it reduced garbage collection processing. PHP does that automatically as the number of active objects goes beyond 10'000. In short, this helps to reduce memory usage at the cost of execution time and is meant for long-running processes that do heavy processing. It should be avoided in web requests.
Like many other caches in Drupal, token info contains a large amount of translation objects. Not having to load the token info meant that web requests no longer reached that magic number, resulting in an additional performance improvement.