I see there are great comments already, but let me condense them and add the missing pieces:
Why hashing the previous proof into the current proof?
As already indicated by ISMSDEV, keybase is essentially building an append-only data structure, an immutable log. The idea is that by incorporating the previous proof, you not only sign the current statement but reassure your knowledge of the previous one, as well.
Why is such a chain a good thing?
Append-only data structures have some nice properties: The sequence is fixed and this is easy to prove and verify. Assume you have a chain like this:
A -> B
Where A is the first proof and B is a proof that incorporates the hash of A. If you now want to later add a proof X that "happened" between A and B, you can embed the hash of A to make it a successor. However, the forked chain now looks something like this:
X <- A -> B
If you would really want X to be part of the chain, you would need to create a new B' that incorporates the hash of X instead the one of A. This would look like this:
A->X->B'
Now the nice thing is that this will render the existing proof of B (the signature) wrong, since the signed content changed. Hence, people can detect this, because the head is now B' instead of B.
To make this more clear, if you have a long chain, such as:
A-> B -> ... -> Z, then you can verify no element of the whole chain ever changed by remembering only the current head of the chain. If at ANY point in the chain something is changed, all elements following would need to be recreated and the top element('s hash). So for a service that continuously publishes the chain and hence the head signature, you only need to remember this one and as soon as the chain changes (probably new elements were appended), you just need to verify everything from the head you already had and after that, remember the new one.
If you are interested in more details, Keybase explains some more details of their approach here.
About committing to the Bitcoin Blockchain...
Ok so what I explained above already holds without Bitcoin. But why now also push to the Bitcoin chain? Essentially, Bitcoin users/clients are continuously checking and verifying the Bitcoin chain to be an append-only log, a public, timestamped ledger. This gives us a public, sealed log of events that is secured by a large, global community. Now people started to exploit this by committing data, such as hashes, to the Blockchain in order to securely and irrevocably timestamp their data. The important part here is that in contrast to a sig chain that you as a service owner publish yourself, you cannot rewrite history. For you as a Keybase user, this means the following: If, at any point in time, the head hash available through the Keybase service and the one hashes into the Bitcoin Blockchain at that time diverge, you now something is fishy. The Keybase people call this "Be Honest or Get Caught". You cannot achieve this by posting to a web page only since it can change any time. The Bitcoin Blockchain however is (almost*) unchangeable.
(*) Of course, Bitcoin is not perfect as well, but the probability or attacks that achieve large-scale history rewriting are tiny (see 51% attack).
So what's the bit picture
The big picture is that companies like Keybase put a lot of effort into building crypto software that reduces the amount of trust you have to put into the creators/service owners to a minimum. Beside establishing transparency through open sourcing code, publishing the sig chains, hashes etc allows customers to even use the service if they do not trust it. The idea is that you as a service provider cannot cheat your customer.
Ok so that was a long answer, but I hope it will clear things up. I just felt that there is some context that needs to be mentioned when talking about such things.
