2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch.
3) A PoC not existing provides a false sense of security. Just because one is not published does not prevent attackers from creating and using an exploit (in many cases before the vulnerability is disclosed).
For 2, not releasing a PoC could be even better. Someone else from the advisory might come-up with an even more clever angle. With the PoC released and it being so intricate, there is less motivation, so less surface area is explored in this case.
For 3, yes it's always false sense, that's why the PoC release being delayed should not influence any appropriate reactions anyway.
4) There is some fame in being the first to publish a full exploit. Not as much as publishing a vulnerability, but still.
If the exploit is released immediately, that chance becomes effectively nil.
Of course this doesn't change the fact that everybody should apply the patch ASAP, but delaying the exploit simply adds some delay to the bad guys.
I don't have any useful numbers, but that seems to leave many novice sysadmins vulnerable to script kiddies simply due to not being around right at the patch release time.
I could be wrong, though. And even if I'm not, perhaps it makes more sense to do things this way, but I'm not (yet) convinced.
Researchers put Shellshock proof of concept exploit code into fuzzers[0] and managed to find five more bugs subsequently[1].
Heartbleed required a patch to OpenSSL, which is typically a dynamic library. I'd wager that without publicly available exploit code to test with many admins would have just installed the patch and failed to restart the server processes, leaving their systems vulnerable.
The solution to improving patch deployment timelines is automated updates, not having admins always online. Admittedly this is still an area that is underdeveloped.
[0] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-...
[1] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
Time to respond is always valuable. Amateurs rushing out patches can cause as many problems as buggy software, especially if the patches are buggy.
2) How many security researchers actually start doing this so soon after the PoC is released that delaying the PoC by a short time (even a day would greatly help many admins) would have any effect on them?
3) This is a good argument against a long delay in releasing a PoC. I don't see how it is relevant to a short, pre-announced, delay. It is unrealistic to expect every vulnerable system in the world to be patched at the same time, immediately after the patch is released.
2) In this case, probably none.
3) The real false sense of security in this case is the notion that the patch obscures the bug meaningfully more than the exploit code does.