You are essentially correct in your last paragraph:
Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.
Though, as mentioned in comments, and in various places around the internet, the idea that a signature is "signing with the private key" is not quite right, it's like saying that a motorcycle is a mechanical horse; it's kinda right (and if you're talking to someone from the year 1685 then it's probably the best you can do) but it's also completely wrong.
So I'm not sure where you got that image from, but I would be wary about anything else they've said, since they are clearly over-simplifying.
I think you already have the core idea, but I'll try to add some more context.
Let's say you're in some sketchy foreign country and a complete stranger walks up to you and says "Hi @Noob, I have a letter for you from your mother." Before you open the letter there are two things you probably want to know: 1) did this letter really come from your mother? And 2) did anyone modify it before giving it to you? In information security these questions are known as authenticity and integrity, respectively.
Digital signatures accomplish both authenticity and integrity, let's talk about integrity first.
Data Integrity
With this question we want to prove that the message has not been intercepted and modified while in transit. To do this we will use cryptographic hash functions with the idea that if two messages have the same hash code, then with a 99.99...% chance they are the same message. (The 0.0...01% chance that two properly formatted English messages have the same hash is actually exploitable, and is called a hash collision attack, but we'll ignore that here.)
So when I send a message, I'm going to attach to it a hash of the message so that the recipient can compute their own hash of the message and check that they match (that's the right-hand-side of your image "Identical hash validates data integrity"). But what's to stop the mail-man from replacing both the message and the hash with new ones? Well, we'll solve that at the same time that we solve authentication.
Data Authentication
In this question we want to prove that the message which claims to be from your mother, did actually come from your mother. To do this, we usually get the sender to include something that only they could have done, for example you sign paper by scribbling your name in a way that nobody else could possibly copy, ancient kings would press their rings into wax (assuming that nobody else has a copy of that ring). With digital signatures we are going to sign a small piece of sample data and send it along, that way anybody can try decrypting it with the public key in the sender's certificate and make sure that it matches the original sample data. Now, instead of signing any random piece of data, we'll sign the hash of the message and kill two birds with one stone. When we check that
decode(received_hash, sender_public_key) == hash(received_message)
we are actually verifying both authenticity and integrity in the same step, since the only way this will pass is if the sender owns the matching private key and the message has not been modified.
~~ Edit in response to your comment: ~~
How do I know that the public key that I have is actually for my friend, and not for an attacker pretending to be my friend?
That's what certificates are for.
The question has a different answer depending on the type of trust model we're using, so let's look at the two main ones:
This is the system used by PGP where each user creates a certificate for them self and gives it to their buddies. The first time you give your cert to someone you have to do it carefully, like on a USB stick in person, or once they have it, have them encrypt something for you and make sure you can decrypt it properly.
Once you have a certificate that you trust for someone, then you can encrypt for them and verify their signatures without any problem.
There's also the Network of Trust (aka "Web of Trust") idea: you can add your signature to anyone's key to endorse that it's genuine. Let's say I'm good friends with Bob, and he has endorsed Alice's cert, then I'm probably OK to trust Alice's cert.
This model gets it's trust by having all certificates generated by trusted servers (called Certificate Authorities). In this model, the job of the CA is to make sure that the person is who they claim to be, before issuing the cert to them. For example, if someone submits a request for a certificate tying pub_key to bob@example.com and 1-800-123-4567, then the CA might send a one-time code to bob@example.com and make sure he can get it, and might try calling 1-800-123-4567 and ask "did you just order a cert?"
