This answer has 2 parts, the 1st on "quantifying" the security of unbroken ciphers, the 2nd on the choice of ciphers for different usage scenarios.
If (on a scale of 1 to 10) AES is 5 and Serpent is 10, what would ChaCha be?
First, you have to quantify their security in order for the scores to be meaningful. The quantification must have a basis, such as "security margin" mentioned in the comments.
This answer does not intend to provide concrete values for the scores or detailed formula, but provide a outline on how it might be calculated.
With "security margin" as quantification metric, we can proceed as follow: Most ciphers operate iteratively in rounds, each round increases the diffusion and confusion of the input - the amount diffusion and confusion obtained in each rounds are usually an order of magnitudes great, so the quantification should be an index rather than a factor.
With these in mind, we can look at
$r$ the number of rounds each cipher has,
$r_a$ the number of rounds attacked, and
$w$ the time-space-query (optionally success probability) tradeoff required for the attack. This is measured in security-in-bits murdered by the attack, divided by bit length of the key.
We get a rough score for the index of security margin of the cipher:
$$ r \over {r_a \cdot \log(w + 1)} $$
Because we're considering both the threat and the feasibility of attacks, multiple attacks must be considered for a given cipher to find its final actual minimum score.
I'm looking for ...
This question asks for security at rest of data in the cloud, but others seeing the title of this question may look for something slightly different.
ChaCha is notable for its inclusion as "stand-by cipher" in TLS, as such, the reasoning led to such decision is worth analyzing. We'll reference https://datatracker.ietf.org/doc/html/draft-mcgrew-standby-cipher-00 for this purpose.
The first thing to consider, is, how easy is it to change the cipher?
For internet transport protocols, changing cipher is as easy as re-connecting to the server and negotiate a new cipher. The biggest burdon is on library implementations to add the support for that cipher.
For data at rest (in cloud, or offline), it'll be easy for new data to be encrypted with the new cipher. For existing data, we'll have to "trans-cipher" them by first decrypting them with the old cipher and re-encrypting them with the new one - this is a long and slow process with possibility of unexpected failures.
For hardware devices, changing the cipher will often be impractical without replacing the hardware in entirety.
The 2nd thing, is balance of diversity of paradigm, verses the burdon of supporting multiple algorithms.
The linked IETF draft set out explicitly, that, the stand-by cipher should have a different design than AES. This way, non-generic attacks that're applicable to AES will not be applicable to the new stand-by cipher (and a 2nd stand-by cipher may be sought when such attack to AES is found).
The linked IETF draft also set out, that, in order to lighten the burdon of implementations, only 1 stand-by cipher is to be selected. A clever stratagy for prosumers would be to encrypt files of different importance using different ciphers (and keys of different strength), but this have to be balanced with availability of support of new ciphers in older softwares. Otherwise, most-needed files encrypted with newer algorithms may not be readable using older softwares.
I'm looking for the best combo of security and modernism to store files long term in the cloud.
