What reason could he possibly have to give them to Nitter, which has at its primary purpose undermining their conversion and engagement attempts?
The old token was the twitter web token. I suspect the new one is one of the mobile clients. Maybe new tweetdeck. Though probably the iOS client token makes the most sense, being the hardest to rotate on a whim with app store review.
The clients currently work logged out (exempting rate limits) and it's not like you can upload a per user copy of the app to play store/app store, so that root of trust needs to start somewhere which is what the nitter team can extract.
Hmmm... I was thinking you could limit based on the unique identifierForVendor[1], but without a way to verify that a given id is legit this would be easily circumvented. An API whereby Apple cryptographically signs a vendor/device-specific ID so you can effectively rate limit without needing any personal info whatsoever would be nice.
A device specific ID would be a fingerprinting mechanism that would conflict with the privacy goals though? It would then have to be resettable, like the ad identifier already is.
They already have a device specific ID, this isn't asking for a new ID. See the link above. It's not considered a fingerprinting mechanism because it's only specific to a device/app-vendor pair, so can't be shared to fingerprint across apps.
The problem is you can't use it for rate limiting because a bad actor could just generate a random ID and use that. That's why an endpoint for validating a given ID was issued for a particular vendor is required for a privacy-preserving anonymous rate limiting implementation.
