You're right that this is an oft-misstated reason for avoiding doing so. Layering encryption this way can only decrease security (in a theoretical sense) if the key and/or encryption algorithms aren't independent of one-another. If both are secure algorithms and you use two independent keys, the composition is at least as strong as the strongest of the two.

The real reason is that the risk of a catastrophic AES break is less than the risk of you mis-implementing this feature. As a real world example, take this [bug in OpenSSL](https://marc.info/?l=openbsd-tech&m=144472550016118) that was intended to prevent DES weak keys.

A more theoretical example of a buggy implementation might be actually a very narrow interpretation of the original point. If you reuse the same key between both algorithms (or, generally, using keys that aren't independent of one-another), it's possible for the second cipher to "undo" the work of the first. A trivial example is AES-CTR(k, AES-CTR(k, pt)), which undoes the original encryption. A less-silly but potentially problematic one might be ChaCha20(k, Salsa20(k, pt)). The two algorithms are different, but very similar in design. There's no known issue with combining them in this way, but it would make me extremely nervous to see such a construct in the wild.

So in a sense we've come full circle. As I pointed out, the real reason is that you're more likely to introduce a bug implementing layered encryption than you are to prevent a catastrophic failure of your cipher. But ironically, one of the more likely instances of a buggy implementation is reusing the same key for both ciphers, which is something along the lines of what the grandparent poster indicated.

As a postscript, one other reason is performance. AES is hardware-accelerated, but other algorithms aren't (though ChaCha20 is extraordinarily fast in general-purpose hardware). Layering means a performance penalty, which is a generally minor but still very valid reason to avoid layering.