Overview. Your proposal is not secure (see below for cryptanalysis). That's why it is not a reasonable alternative to authenticated encryption.
A little more background. Why do we need authenticated encryption? It is because encryption without authentication is not secure. Many developers don't know this, so they end up with an insecure use of cryptography.
It is possible to manually use both an encryption algorithm and an authentication algorithm. For instance, you can use the encrypt-then-authenticate construction using a secure encryption scheme and a secure message authentication (MAC) algorithm. However, this requires some extra effort from the developer.
Authenticated encryption was designed as a single primitive that is easy for developers to use, and that provides all the necessary authentication (so you don't have to do some extra stuff to provide security). Thus, it is helpful for security. Some authenticated encryption schemes also have the benefit of better performance than separately encrypting and then authenticating, but that is a secondary consideration.
Please read Don't use encryption without authentication for more detail on this subject.
Cryptanalysis of your scheme. You proposed that we append a hash of the message before encrypting: in other words, C = Encrypt(K, M||H(M)), where || represents concatenation of bit strings. This scheme is not secure against chosen-plaintext attacks, with many encryption algorithms. For instance, I'll show an attack against your proposal, if you are using CBC mode encryption (though the attack applies to many other modes of encryption as well).
Note that if a man-in-the-middle truncates a ciphertext that was generated with CBC mode (at a block boundary), the recipient won't notice the truncation, and after decryption will receive a truncated version of the message that the sender was trying to send. So, with that background, here's the attack. Let Alice be the sender, Bob the recipient, and assume a chosen-plaintext setting.
The attacker chooses some message M that he wishes Alice would send: but Alice refuses to send it (maybe M says "transfer $100 from my account and give it to the attacker", or something). The attacker constructs some other value X such that Alice is willing to send M' = M||H(M)||X (maybe X says "just kidding! don't you dare"). The attacker convinces Alice to encrypt and send M'. This means that Alice is going to transmit the ciphertext C' = Encrypt(K, M'||H(M')) = Encrypt(K, M||H(M)||X||H(M')). The attacker plays man-in-the-middle, captures C', and truncates it while it is in flight. Let's call C'' the truncated ciphertext. Bob will receive C'', decrypt it, and then check the hash. If the attacker chose the truncation point correctly, then after decryption Bob gets M||H(M), checks the hash, sees that the hash is correct, and concludes that Alice must have sent M.
In other words, at the conclusion of this attack, Bob concludes that Alice authorized transmission of the message M -- but she never did. (She authorized the transmission of some other message, but not M.)
Whether or not this is a serious security vulnerability will depend upon the context in which it is used, such as the format of the message M. But, empirically, in at least some applications, this kind of attack could pose a serious danger to the application. Therefore, cryptographers consider that this is not a good general-purpose scheme.
Given that there are good schemes out there which have been carefully vetted and proven to be secure for general-purpose use, cryptographers would recommend that you use one of those general-purpose schemes (such as authenticated encryption, or the encrypt-then-authenticate construction) -- and in particular, don't use the one you mentioned.
