The API call to purge cache by URLs is already rate limited a little differently than other API calls. It's rate limited by the number of URLs you are purging rather than API calls.
The single-file purge rate limit for the Free subscription is 1000 urls/min.
The system already groups URLs into a single API call for each post (there are potentially up to 4 URLs that get purged with each purge action).
For sake of math, let's say each post created or deleted needs to purge the max (4) URLs. Currently it's purging those 4 URLs with a single API call. So you start to hit the API limit allowed for purging URLs when you get to 250 new or deleted posts per minute.
You
can purge up to 20 URLs per API call, so the only real difference here is you get to the 1,000 urls per minute limit with 50 API calls rather than 250.
Since the limit is per URL (not per API call), the added complexity of having a purge queue system doesn't really do much. The API requests have already been moved to the backend so they don't affect the user at all (they are done with the XenForo job manager system). Besides the additional complexity of putting URLs into a purge queue system, it would be slower for the URLs to actually be purged on the backend (you would need to add some sort of wait time to do the purge so additional URLs can be queued so they can run together).
Either way, the limit is 1000 urls/min, regardless if it's done in 50 API calls or 250.
For very high traffic sites getting hundreds of posts per minute, it probably makes sense to not purge the cache in realtime. Realistically, are unregistered (guest) users really sitting there reloading a thread continuously to see if there are new posts, but not registering? The guest page caching is more to make the site extra fast for guest users coming in via something like Google search... so how important is it really that the user sees a post on the last page of the thread that happened in the last couple minutes? Again, it only applies to unregistered users anyway...