From my perspective, I'm not the one not listening.
My point was, and is, that the "Limited damage" case of Heartbleed is that there's a 99% chance that your keys weren't stolen. Of course, you can't verify that.
So your position is that because you can't be 100% absolutely positive that your keys weren't compromised, you should regenerate them? Because that's what I understand you to be saying.
And if it is, you better go regenerate your keys again. After all, you can't be 100% positive that someone didn't 0-day your system while you were reading my post. Hmm, you need new keys again. How can you be positive that the ones you just made weren't compromised to? Better make some new keys a third time.
Obviously I'm being facetious here, but there's more to it than that: if you're really really paranoid about security, it actually makes sense to change keys occasionally even if you don't change the algorithm or implementation. Why? Contingencies: if your key is compromised, it limits exposure. Even if you assume that once an attacker is able to capture your key they'll be able to capture all future keys, it still limits the amount back in time the attacker will be able to retroactively do it.
Better make another new key.
Because you're not making new keys, you're doing a cost-benefit analysis that generating new keys each time I tell you to is not in favor. Just as most people hopefully do the cost-benefit analysis related to the heartbeat vulnerability and determine it is.
The "benefit" is really more of a "anti-loss" here, but it's related to the risk you assess if you stick with the old keys. If you judge that your risk of exposure is higher, than the benefit of changing keys is higher, and so you're more weighted to change keys.
Suppose you're a relatively low-importance site, and based on the importance (or lack thereof) of the information protected you decide that if you're 95% sure or better that you weren't compromised you're not going to bother to change keys because the cost-benefit ratio isn't in your favor. (Remember, if you needed to be positive you're not compromised, you'll be continuously making keys. Have you made a new key yet?) Now if you have an OpenSSL deployment without a hardened allocator, you say "I'm 90% sure that I wasn't compromised." That's below your threshold, so you make new keys. But if you have a deployment with a hardened allocator, mayde you say "I'm 99% sure that I wasn't compromised." That's above your threshold, so you don't.
I made those numbers up of course, but that's the general idea. A hardened allocator provides a potential benefit. As I said in another reply, I don't see any cogent argument against that. The only objection I see is if you think that people are entirely incapable of making the kind of 90%/99% guesses I said, and thus removing the option for them to use a tighter threshold will artificially push people toward the failsafe option. (Actually that's not a bad argument, to be honest.)