Earlier quoted context omitted.
An "API neutrality" proposal would make more sense. E.g. Apple wouldn't need to develop iMessage clients for non-Apple platforms, but they would not be able to block non-Apple platform client apps (developed by anyone) from connecting to the API. See HTTP, IMAP, Exchange, NFS, Windows SMB, etc.
Apple develops iMessage, and gives it away for free on iOS, as a way to make its own platforms more attractive. Let's say this hypothetical "API neutrality" proposal were to go through -- note the actual letter from Blackberry's CEO never mentioned the phrase "API"[1] -- then Apple might simply stop developing iMessage. Unless your hypothetical law forces them to make the API available and keep it available indefinit…
Or they might find other ways to make Apple platforms more attractive, without forced bundling of service APIs and platform clients.
Today, many customers use Apple's Mail client to access multiple email services. Since iMessage competitors (e.g. WhatsApp, BBM) would face the same regulations, Apple would have the option of supporting multiple message APIs in their client, giving customers more choice among competing services, and giving customers more choice among competing clients on each platform. We have years of data on Apple restrictions on web browser rendering on iOS, they have many possible mechanisms to advantage native clients of open APIs.