Why do one-time pads not provide message authentication? It is often said that one-time pads do not provide message authentication. But, if you and I have a one-time symmetric key, and I send you a message, and it is not complete gibberish, is that itself not message authentication? The probability of you getting a non-gibberish message is, I would have to spam you a noticeable quantity of messages to get one that decodes to something resembling what you expect to get.

Update: I was mostly considering attacks where ciphertext is not known, but the recipient is known. In that case, to try and guess what to send them is impossible, and the message seems like it is inherently authenticated. An attacker intercepting the ciphertext could, like the answers say, alter a bit here or there, maybe it could be good to have a message authentication hash as well.
But, if you and I have a one-time symmetric key, and I send you a message, and it is not complete gibberish, is that itself not message authentication?


The informal criterion of "not complete gibberish" that you are applying here has two problems:


Malleability: It is trivial to modify OTP-encrypted ciphertexts so that they will decrypt to something that's unlikely to be "complete gibberish";
Computers are dumb: It assumes that the decrypted message is read by a human being possessed of common sense instead of acted upon by a dumb computer;


Malleability

This is the property many ciphers have that an attacker that doesn't know the key can nevertheless modify a ciphertext in such a way as to cause a predictable change in the plaintext it will decrypt to.  One-time pads and stream ciphers (the computationally secure variant thereof) are subject to one particularly trivial form of this:


If you flip any bit of a ciphertext, that causes the corresponding bit of the plaintext to flip.


This means that if I flip a bit in a ciphertext, the resulting fake plaintext will be minimally different from the real one. I hope you agree this means it's unlikely to be "gibberish."

In comments you've expressed skepticism that an attacker could exploit that to fool a recipient, because they'd have to know or guess a fair amount about the plaintext that corresponds to a the ciphertext.  But that's a condition that is often met in real life—for example we routinely encrypt network protocols and file formats that are publicly specified and such that an attacker can effectively guess the protocolar "skeleton" of encrypted messages.  And we don't want them to be able to exploit this to modify that skeleton.

Computers are dumb

The other problem is that the scenario you're implicitly contemplating—a human being, possessed of common sense, reading a single decrypted message—is not the norm by any means.  Most decrypted messages are acted upon by computers, slavishly literal and poorly programmed machines that will happily repeat the same humanly-absurd mistake billions of time per second with unintended consequences that nobody predicted.  We can't rely on some common-sense human notion of "gibberish" to reject forgeries—we need a fool-proof mechanical way of rejecting forgeries, one that not even a computer can goof up.

Example: EFail attack

One recent real-life example that combines these two motifs is the EFail attack on encrypted email.  It exploits:


Malleability: The attacker is able to modify an HTML emails' ciphertext to craft a forgery that decrypts to an HTML image tag with the original plaintext inside its URL;
Computers are dumb: Many email clients will obliviously decrypt that forged message and automatically make the HTTP request for the forged image tag before showing the plaintext to the user.


EFail is an attack against CBC-mode encryption, not stream ciphers or one-time pads, but cryptographers' general attitude to malleability is that it should not be allowed in practical systems, period.