I'm not sure why that would be true.
I posit that such a system could work like this:
* An asymmetric keypair (e.g. RSA or ECC) is generated and stored on Apple's servers. The private key is encrypted with the user's password, which is not retained by Apple except in a hashed form.
* When a device is added, the private key is decrypted using the password and sent to the device.
* When your password is changed, either A) the private key is decrypted with the original password, and re-encrypted with the new password, or B) the private key is decrypted, used to decrypt all data, thrown away, and a new keypair is generated, with which all data is then re-encrypted.
It is, of course, obvious that Apple could, in theory, capture your plaintext password somewhere in there and use it to decrypt messages.
There are ways around this, such as devices doing the key decryption locally and only ever sending a derived/hashed form of your password to the server, and using a different derived/hashed form for encryption.
However, since you can log in to iCloud and Apple's store with your Apple ID in a browser, there is still no effective defense against Apple capturing your plaintext password (unless you care to perform a detailed inspection of a bunch of JavaScript every single time you load any content from Apple's servers).