The permissions team agrees that onload permission requests are incredibly irritating and shouldn't be done. We also strongly feel that such requests *should* be made in context.
We've been looking into a number of things to try and discourage onload requests. Unfortunately, detecting if a permission request is made on page load (or very soon after page load) is pretty tricky to do accurately. Like Ojan said, any change we make could also break interop (Chrome won't let you call geolocation/notifications/etc. when others browsers will).
We've reached out to various sites which use onload prompts to try and encourage them to not do that. A lot of these sites have basically ignored us, e.g. Facebook, which hits you with a door-slam black background page with a permission request after you login (see attached). They've basically said, "this works best for us wrt CTR" when we tried to tell them not to do this. This is an outlier case, but it's representative of the attitude we've often encountered.
There are also sites which genuinely won't work properly without a permission grant as early as possible (weather sites, map sites, etc.). In these cases, we don't necessarily want want to prevent a prompt, because it will only confuse typical users who might not understand why the site isn't working properly.
We have early metrics suggesting that permission requests are 3-4x more likely to be granted by users if they are accompanied by a user gesture - i.e. that they're (probably) triggered by the user explicitly clicking on something on the page and directly showing interest in a feature which requires permission. We're probably going to try an experiment where requests for permission without a gesture are simply ignored (and maybe even work to get that codified in the spec).
So yes, in summary, we know onload prompts are annoying. We're working on solutions to try and address the situation, but it's a challenging problem for a bunch of reasons.