In response to it being a ‘chore’ to cache followers and being a lot of unnecessary API calls, from all of my work with channels in the high hundreds of thousands of followers, the % time the cache is consist is extremely high, especially thanks to webhooks.
Even when there is an unfollow, which is relatively rare, from my experience they statistically are shorter length followers, meaning you almost never have to do a full poll of the followers, you only have to page through until you discover the unfollower which trends towards the earlier pages.
So even with an unfollow, the window to regain consistency is just a few minutes, and while I don’t track this specific metric there’s anecdotal evidence that someone who unfollows is less likely to speak in chat. Then even if they do speak in chat, during that window, you have to then ask yourself if mistakenly thinking they’re a follower for that brief period will have a critical impact on your use case.
Like I said though, I work with channels in the high hundreds of thousands of followers, if you do work with channels into the millions, or a vast amount of channels, then I’d be interested on the data you’ve already tracked on this and how frequently the Helix limit is a bottleneck (assuming you have already had an appropriate rate limit increase)
Oh, and as for ‘unfollow events’ like has been previously mentioned that’s something that Twitch has intentionally decided not to include for the reasons already mentioned, which is why webhooks only show follow events.
I’m not saying that a follower tag is without benefits, I’m just trying to point out that some people seem to be inflating problems in using a cache based system, or making assumptions without engineering and testing a system beforehand to see what the performance will be before complaining.