You are wrong. The purpose is to prevent linking the signing operation with the verification operation.
For instance, suppose that I have to identify myself when I ask B to sign the thing (maybe B charges me to create a signature; for instance, when blind signatures are used for e-cash, B is the bank, and B charges money to sign anything, since validly-signed coins are money). Now suppose I want to be able to present the signature later so someone else can verify that the signature is valid. The security goal for blind signatures is that I don't want the verifier to be able to collaborate with B to identify me.
If it is possible to link the signature (presented during verification stage) with the value presented during the signing step, then that defeats the security goal.
If you ask B to sign an unblinded hash, then security falls apart. The verifier (who sees the signature) can pull the hash out of the signature, then collude with B to match that up to the person who originally presented the hash for signing. In that way, the verifier could identify you -- something that's no longer possible if you use blind signatures and only send the blinded hash to B. In particular, given a signature, it is very easy to recover the hash of the message that is being signed: part of the signature verification step involves computing this hash.
So, just sending the unblinded hash isn't good enough. You need to blind the hash before sending it to B for B to sign, in the applications where blind signatures are sued.