Yes, it is. All of the participants in an iMessage chat have consented to have their data stored by Apple. We can all do rough evaluations on how well we think Apple can protect our data.
The wording in the Act appears to not place constraints on exactly what services must be able to interop with iMessage, and it says Apple can't preference iMessage. So presumably the blue bubbles have to go. This means that when chatting in Messages now, one will not be able to know whether it's Apple alone protecting the privacy of the conversation, or whether the weakest link is a company of a single person that started this week using an OSS package to spin up a new messaging app on a Linode VM and was able to achieve parity in iOS messaging simply by virtue of this Act.
That's a very different situation than the status quo.
Similar logic applies to the App Store and payment details, but messaging is egregious because other participants in the chat can make (and potentially change) the security posture of the chat without your knowledge.
(Edit, adding reply to this part.)
> Are you arguing that it's impossible for Discord or ICQ to implement the same feature set as the native iMessage client?
No, I am saying that it's going to be trivial to implement the feature set. I fully expect there to be OSS libraries to implement the iMessage client.
The issue is that when people use iMessage and see a blue bubble, they also know something about how the encryption keys are handled & who does the handling, etc. This Act as written appears to allow any person to install an OSS iMessage server on a VM and achieve OS parity with iMessage, and Apple is prevented from indicating that others in the chat may be compromising the security of the chat. I used ICQ and Discord as examples because Apple exchanging my encryption keys with ICQ is definitely compromising a core feature of iMessage.