First an important point of terminology: the real question should be phrased "Why not just sign the whole message with the private key of Bob, send it to Alice, and verify it with Bob's public key?". Signature and encryption are very different things. We use "encryption" only when the goal is confidentiality; and encryption is performed with the public key of the receiver, rather than with the private key of the sender (as is the case for signature).
With that terminology issue set aside, what the question describes is the rough principle of signature with RSA, where the encryption operation can be carried with the private key instead of the public one. However that does not transpose to arbitrary asymmetric ciphers: their public and private key is often so different that there's no way to encrypt with the private key.
Further, there are security issues with what's proposed:
if someone else sends the message we simply couldn't decrypt it.
Not true. If an attacker prepares the message as a legitimate sender but a different key, the message could be decipherable, only most likely into gibberish. So at least we need a procedure to recognize real messages from gibberish, and that's not easy (it might be impossible if what's signed was already encrypted, which is common practice).
Also, an attacker is not restricted to applying a proposed protocol with a different key. S/he can alter or combine existing cryptograms, and that opens to attacks. That's a reason why secure RSA encryption and secure RSA signature differ by more than an exchange of the role of keys.
We usually sign a hash of the message, rather than the message, primarily because the signature schemes that we use can only directly sign small amounts of data (in the order of tens to a few hundreds bytes). A hash reduces an arbitrarily large message to a small size (32 or 64 bytes are common), that we can sign in a single chunk. Signing the hash is as secure as signing the message, because (for a good hash algorithm) we do not know how to make two different messages with the same hash (collision resistance). Without this hash trick, we could still sign, but we'd need to break the message into numbered pieces, and sign each piece individually. Signatures tends to be several times larger than what they can directly sign, and at least one of signature generation or verification is typically compute-intensive; thus hashing saves bandwidth and improves performance except for very small messages.
For many signature schemes, there's another reason: hashing the message is necessary for security. Otherwise, some property of the signature scheme would allow forgery: perhaps some few messages would have a trivial signature, or the signature of a message could be derived from the signature(s) of some related message(s). With addition of the hash step, messages allowing such attacks can not be exhibited, because (for a good hash algorithm) we do not know how to make a message with a particular hash value (preimage resistance), or more generally with a special property.
