The Heartbleed bug indeed allows other parties to read memory outside the intended space, but it does not allow you to read memory from other processes. The start address cannot be modified either by the attacker, it really depends on the memory allocation algorithm which memory ends up to be returned. Most likely this is memory of a recent HTTP request (for webservers and webbrowsers). For busy webservers, there is a high chance of getting completely different data back because the memory was overwritten while serving other users.
Cloudflare investigated the possibility of getting a private SSL key out of the nginx webserver, but found it highly unlikely to squeeze the private key out. The main argument is that the nginx webserver loads the private key very early during startup. Not much memory is allocated/used at that time, so the private key is stored at a low address. When new requests come in, more distant addresses are used, so they think it is hard (and likely impossible) to get the key. That's why they have put up a challenge that ask testers to prove otherwise.
Note that there is no really hard proof that it is not possible to get keys. The paranoid (and safe) stance is then to assume that it is possible (even if the chance of getting hit by a meteorite is higher). To prove that it is not possible to get keys using this single bug, one should check carefully how the memory allocater works and how other external factors may affect the addressing.
The researchers were able to get the private key in "lab conditions". What were these conditions? If they run a custom webserver using OpenSSL on an low-memory embedded device, then this may indeed make it much easier to get the private key, but it is not realistic.
Regardless of whether private keys can be leaked or not, it has been shown that recent HTTP requests and responses can be read from memory. This includes passwords (see Yahoo, I know someone who got 3k passwords in a short time), business documents, source code (including database credentials), login tokens, session IDs and more. Although the main private key was not stolen, it is still quite possible that the premaster secrets were leaked which would allow someone who sniffed the network to decrypt the encrypted data.
As for auditing, you cannot see in webservers' access logs that it had been attacked with this bug. Only with a packet capture, you can tell.
Since attacks are quite stealthy and the bug allows remote attackers to easily gather data that is normally not accessible to the outside (source code) or should be encrypted (passwords), in my opinion Heartbleed is pretty severe. It did get much media press, but that seems to be justified.