It seems you may have a few different things to consider with this. A couple of considerations for this:
So if reports 1, 2, and 3 contain 75% of the total in the queue, they would get 75% of the threads, not 100%.
You can affect the number of threads through MaxQueueThreads or by adding/removing CPUs. You can affect what services are implemented or ignored by SSRS (those threads) using the configuration file and changing the yes/no values for things like IsSchedulingService, IsNotificationService, IsEventService. But you really can't control what percentage of threads are doing what as that is something in Microsoft's code.
Another thing with that would be the "queue" and the size. Since it's not really a queue per se but rather a piece in the flow for the process, nothing in those tables knows anything about the totals or percentages or whatever else is in those tables. It is also dynamic so I'm not sure how you would determine something like 75% as you need to ask at which time or at what point. This looks like it would require that every subscription be fired at the same time if you wanted to prioritize the subscriptions based on all of the subscriptions.
Another consideration would be in regards to:
manipulate the Notifications or Events tables (or the procs that actually pick the work) to prioritize them
The processessing of subscriptions is not done only through the stored procedures. It also involves the methods for the web service which you won't be able to modify.
Modifying the tables really isn't an alternative due to how much will break. You can affect the events table to some degree by calling AddEvent or starting the subscription job - those just put the row in the event table for the given subscription.
There are third party apps that manage subscriptions that you may be able to utilize.You could also look at writing your own processes for managing the subscriptions using the Web service, SOAP API. That's essentially what the third party applications do.
Sue