I noticed that a script I run to get channel statuses (image, live state, follower count, display name, that sort of thing), currently for around 300 users, was slower than I expected, so I timed every API call and noticed that https://id.twitch.tv/oauth2/validate was taking about 3x longer than any /helix API call. When I skipped it and relied on the next call in the queue, https://api.twitch.tv/helix/users, to return a success or failure instead, the script speed went from 180 seconds to 80 seconds. This one call was slower than the three user info, follower count, and live status calls combined. Needless to say, I’ve commented out the validate call entirely for now, but I thought it might be a good idea to report it as well.
The OAuth and Helix API systems are different services behind the scenes so will likely have different request times just due to their nature.
As for calling the validate endpoint, if you were previously doing it before every request then that’s excessive and not needed at all as the nature of a response to a Helix request alone will tell you if the token is valid or not. One of the main uses for validation is things like logging in to a website where a user could potentially connect the site to Twitch to use as a login, the site then requests the users profile images and might have no further Helix requests, so the Validate endpoint can be used periodically to ensure the user still has their Twitch account connected and if not the site can logout that session.
If it’s a server side app, then when you refresh the token that’ll show if it’s valid as if it’s not you wont get new tokens. So if it refreshed successfully there’s no need to keep validating it each request. If your app makes no Helix requests after a period of time then you could use the validate endpoint to check if it’s still valid, but if you are making Helix requests then it’s entirely redundant.