you're developer are pushing branches to the main repo and not to their own fork.
That's correct. They are all organisation members so philosophically, the main repo is really their (shared) repo. But pragmatically (and primarily), it is done this way due to the inability to prevent Jenkins from processing PRs from untrusted sources. Jenkins can be told to refuse to process the Jenkinsfile from an untrusted source, but cannot be told to completely ignore PRs from untrusted source. But Jenkins can be told to ignore PRs from forks. So the proxy for "untrusted source" is any fork.
having a delay of some sort would be useful
So you are suggesting that there is in fact no delay? At all? I cannot see how that is ever going to work. The branch will always show up before the PR no matter how quickly the developer can get to turning a branch into a PR. I guess this is trying to rely on Jenkins being slower to notice the new branch than noticing the PR? Surely you can see how this is fatally flawed.
how long should that delay be?
Yes, this is a good question. Probably begs to be configurable. But even if not, some number of minutes seems reasonable. At least that way I can say to my users "you need to make sure you create your PR within ... of pushing your branch or you will get this ugly behaviour". Right now I cannot tell them anything other than that this is a nasty Jenkins bug and they have to just live with it.
I'm think this issue should be closed as "By Design".
Or left open as "Needs redesign"?
Use forks and discover PRs from forks
This simply cannot be done. There are a lot of people that agree with me on this. We are simply not allowed to just let any random stranger run whatever (perhaps nefarious) code they can push to a PR for to run on our Jenkins. The lack of this ability is griped about quite frequently.
use "Filter by name (with wildcards)" or "Filter by name (with regex)" discovery strategies
That might be workable. Funny enough, it's more or less the same solution as I coded up earlier this morning when I commented on this issue earlier.