This was discussed quite a bit in the Twitch app chat room, and there are quite a few issues with doing something like this.
First off, Twitch want to keep to the specification, so it may not even be possible to implement something like this without breaking the specification.
I might have overlooked that, that this topic was already discussed in detail
Secondly, how would you even implement something like this? With an API request, say for example getting user data, it’s easy to make a request for multiple users as it’s just the addition of &id=… for each user. A webhook subscription on the other hand requires multiple parameters for each: hub.callback, hub.mode, hub.topic, hub.lease_second, hub.secret.
Why not limit this one to allow only multiple ids? this wouldn’t be as flexible but would probably be the standard case because right now your basically duplicating that call for multiple users, but yeah since i don’t know the specification in detail this would probably still violate it. But i understand now why they decided against it.
Authentication in a bulk subscription can also get tricky. What if one token is invalid, so one subscription needs to return an error, while the others need to return success?
But is it really such a problem? at the moment every app access token is allowed to subscribe to any users on/off hook so why not allow requests with one app access token for multiple users?
So overall, bulk subscription would be quite a mess, unless the devs have thought of a clean way to do it that they haven’t mentioned yet.
With a 10 day lease time, 1000 separate calls really isn’t much at al. You can create all those subscriptions over the first min or two of your apps startup, then once they’re all up, stagger the resubscriptions and you’ll never need to have a big burst of subscriptions again. The devs have put a lot of work into trying to make the process as painless as possible, even for devs with needs to subscribe to tens of thousands of topics, the long lease time and staggered subscriptions really helps even on that scale, and for large initial subscriptions the request for a higher rate-limit is processed much faster than when it was initially made available.
Yeah i get now why they didn’t implement it yet (or won’t). A full solution would probably entail some problems, also i didn’t know yet that the lease was increased to 10 days, i think it was 3 before, this should make this less of a problem. I was just trying to understand why it is like it is since it seemed like a lot of unnecessary calls to me 
thanks for your write up/clarification 