In the SHA hash algorithm, why is the message always padded? In the SHA hash algorithm the message is always padded, even if initially the correct length without padding; the padding is of the form "1" followed by the necessary number of 0s.

Why is it necessary that the message always be padded?
Well, the entire point of a cryptographical hash function is that no one can practically devise two messages that hash to the same value.

Now, the SHA family of hashes use the Merkle–Damgård construction; that is, they have an iterated hash function, and each invocation of the hash function takes as input a fixed block size (either 512 or 1024 bits in the case of the SHA family).

However, we're interested in hashing messages that don't happen to be an exact multiple of 512 or 1024 bits in length.  So, what we do is define a padding function that takes a message, and converts it into a form that's a multiple of the block size in length; we then run the hash compression function on this padded message.

Now, there are a couple of requirements on this padding function; one of the most critical that if we had two different messages, then they must still be different after padding; if not, then the hash compression functions will work identically, and so those two messages would hash to the same value.

That really is the answer to your question (a); if our padding function didn't modify (pad) messages that happened to be the correct length, then that would immediately lead to a collision.  For example, if we take any message $M$ that's not a multiple of the block size, we could compute $Pad(M)$.  Now, $Pad(M)$ will be a multiple of the block size, and so we'd know that $Hash(M) = Hash(Pad(M))$.

As for the answer to your question (b), well, if our padding function was simply adding zero bits until the padded message was of the correct length, well, that would lead to a collision of the form $Hash(M) = Hash(M || 0)$ (assuming postpending the 0 doesn't cause us to cross a block boundary).  On the other hand, the SHA padding function isn't just appending 0 and 1 bits; it also involves adding a bitlength of the entire message at the very end.  If the question is "why do they add a 100...000 pattern and add a message length', well, I rather suspect that's a belt-and-suspenders approach.  Either would be sufficient in itself (as either would prevent two messages from padding into a common value); both are cheap, and so the designers decided to do both.