Why define CIA in security like this?

You're focusing on a very narrow scope here. The CIA triad is about security of a whole system, not just an encrypted message.

That being said, all elements of the triad do apply to your example:

• Confidentiality: As you mentioned, encryption's primary purpose is to enforce confidentiality.
• Integrity: Encryption does not automatically provide integrity. An attacker could swap an encrypted message for a previously seen encrypted message. An attacker could abuse ciphertext malleability in order to modify the plaintext without knowing the key, e.g. if a stream cipher was used without an authenticity record on the ciphertext.
• Availability: An attacker might delete or corrupt the encrypted message, or leverage a denial-of-service (DoS) attack against the system that contains the encrypted message.

While Polynomial's answer is outstanding, it may aid the understanding of the CIA principle to add examples how each aspect can be broken, and how each aspect can be protected.

Confidentiality

The purpose of Confidentiality is simply put to control "Who reads what?". Confidentiality can be broken if information is leaked to an unauthorized party. What kind of information that is depends entirely on the threat model. I'll give some examples:

• Organized criminals do not want criminal investigators to know who talks to whom. The mere indicator of communication, regardless of the content, is confidential information.
• A spy attempting to defect to another side does not want to be traced back to. The origin of a message is as confidential as the content.

As you can see, there is more to Confidentiality than just the content of the message. Metadata matters as well, and that is hard to encrypt. In general though, encryption is a good way to gain Confidentiality. In those specific examples however, further measures need to be taken to keep all compromising information confidential.

Integrity

Integrity can be seen as the property that a message cannot be modified by an unauthorized party. Since this is often an infeasible goal, a good compromise is that any kind of unauthorized modification needs to be identifiable.

One of the first things you will learn about cryptography is to always use algorithms for what they were designed to do. Encryption is being used to guarantee Confidentiality, not Integrity.

A great example for this is the One-Time Pad. It is achieved by XOR'ing the message with a random key that is at least as long as the message. Let me give you an example. As message, we'll use

ATTACK AT 09:00

and as key, we'll use

jHiA015Ak4012Kf

This will result in the hexadecimal message

2b1c3d00737a15003f140008087b56

An attacker, knowing the rough format of the message, but not the content, can now change the ciphertext maliciously into:

2b1c3d00737a15003f140101087b56

With the same key, this will decipher into

ATTACK AT 10:00

This could prove to be a fatal outcome. The attacker still cannot read the ciphertext, so Confidentiality is still upheld, but by manipulating the ciphertext and the recipient not being able to detect that manipulation, the attacker got what they wanted.

Integrity can be upheld by adding some kind of code to the message that verifies if the message has been modified or not. A hash with a key, a cryptographic signature over a hash, etc. can all be used. The important part is that any modification to the message will be noticed, and that an attacker is not able to forge a valid authentication code themselves.

Availability

Availability is often looked down upon to those newer to security, as a kind of "nice-to-have" goal. But let me ask you: What good is a server that is perfectly encrypted and to which nobody could write to, if it was offline all the time?

Availability can be judged by many metrics, depending on each individual use-case. Sometimes it's uptime, sometimes it's response time, sometimes it's performance. Each of these factors could bring down a business if it was impacted in a major way.

Imagine if StackExchange would be down for "maintainance" 90% of the time, because some skiddie in ████████████ put bringStackExchangeDown.sh in a cronjob to run every 30 minutes. And the 10% where the site was online, it would be so slow that a 54k dial up modem seems blazing fast in comparison.

You would not want to use that site, and the attacker got what they wanted. Sadly, Availability can't be improved by throwing more crypto at it. Availability can only be improved by scaling up and wide, increasing redundancy, and by fixing bugs that would reduce Availability.