The main reason to use a proper cryptographic authentication code is to ensure the very properties you listed. Your proposal of ciphertext and CRC (encrypted or not) fails to provide those.
Let's consider three possible arrangements of data transmission with CRC:
Plaintext message and CRC:
CRC (Cyclic Redundancy Check) is meant to detect errors in transmission or storage.
It is a straightforward algorithm with a single input (the message) and a single output (the CRC code). As such it cannot provide protection against willful modification of the data as anyone can compute the new CRC code.
This means we would need to ensure the CRC cannot be manipulated.
Let's take up your first proposal:
Encrypted message, plaintext CRC:
One big problem here: CRC is not a cryptographic hash function, nor was it ever supposed to be. It has too many chances of leaking information about the plaintext.
The properties in the next section also mean that they can modify the encrypted message AND properly modify the CRC.
Encrypted message and CRC:
One notable property of CRC is that $\operatorname{CRC}(x \oplus y) = \operatorname{CRC}(x) \oplus \operatorname{CRC}(y)$.
block ciphers modes operate using the XOR operator over a mix of plaintext, key, IV, previous ciphertext, etc...
In some cipher modes, XORing the ciphertext is the same as XORing the plaintext. For example, the counter block cipher mode boils down to: $\text{ciphertext} = \text{plaintext} \oplus \operatorname{AES}(IV)$
To fake the message, I can compute $\text{diff} = \text{plaintext} \oplus \text{desired_plaintext}$ and return the following:
- new ciphertext: $\text{ciphertext} \oplus \text{diff}$
- new encrypted CRC: $\text{encrypted_crc} \oplus \operatorname{CRC}(\text{diff})$
I have effectively modified the message and its CRC without having to break the encryption.
You can find further reading and references in the data integrity section of the CRC wiki page.
[EDIT: credit goes to Maarten Bodewes] CRC size limitations:
CRC's are generally limited to 32 bits (although 64 bit CRC's have been defined), which is not enough to provide 128 bits security. Just trying in the order of $2^{32}$ random messages (or separate connections) would give you a chance of ~0.63 to get one right. That's simply to high of a chance even if CRC could not be attacked by other means.
Now it is possible to create a MAC by performing a relatively fast operation over blocks of 128 bits / 16 bytes and then encrypt the result. These kind of techniques are used for GMAC (in AES-GCM) and Poly1305 used within ChaCha20/Poly1305 used in - for instance - TLS 1.2 and 1.3. These still rely on a block cipher for security, but the block cipher is only used once or twice instead of for each block of the message.
Note that GCM and ChaCha20/Poly1305 operate on the ciphertext rather than the plaintext, but that can be considered an implementation detail. Generally you want to verify message authenticity before decryption.
You may also be interested in one of the secure OCB modes (1 & 3) which integrates both authentication and encryption, doing away with any additional (computationally intensive) operations on the data.
