Re: Not exactly...
I think what they meant was "it compromises the presumed privacy of private keys". That is, it's a compromise of a feature of the protocol, not necessarily of any given piece of secret data.
As for the probability that a private key will be leaked by Heartbleed: It really depends on a particular binary running on a particular platform, and often on a particular instance of a particular binary running on a particular platform. The amount of data an attacker can get may be less than 64KB, if the overrun hits an unmapped page. If it doesn't, then it depends on whether malloc1 happened to allocate a TLS protocol buffer close enough to an EVP_PKEY structure.
The problem with the probabilistic argument is that there's no way to know if a vulnerable system has ever leaked critical data in the past. You can test your server now, and it might only expose innocuous data, but on the Nth previous run happen to have put that EVP_PKEY right near the overrun buffer.
And if, say, a vulnerable server does leak its private key, it's easy for an attacker to determine that using automated, parallelizable scans. (Basically, just test every byte string of the appropriate length to see if it's the private key corresponding to the public key in the server's certificate. You can use some heuristics to reduce the work required somewhat, too, though in a case like this it's just as easy to throw more hardware at it; you can do a lot of RSA key checks with a GPU farm.)
So the available threat models basically boil down to "assume my private key has been compromised" and "assume my private key hasn't been compromised", if you're running an Internet-facing vulnerable server. There's just no good way to narrow it down more than that, unless you keep extremely detailed logs.
1Assuming you haven't replaced your system's C implementation's malloc as the allocator for OpenSSL.