No it wouldn't.
Here's how it works today when I want to send a message to mobile user +123 456789. Let's assume I have an iPhone with iMessage and that I've turned SMS on as a backup.
1. I go to iMessage and send the message to +123 456789 (either listed in my Contacts or manually input; either way works).
2A: The number is registered to iMessage and online. The message gets sent via Apple's proprietary protocol.
2B: The number is registered to iMessage and offline. After timing out the message is sent via SMS protocol.
2C: The number is not registered to iMessage. The message gets sent via SMS protocol.
Here's how it'd work in the hypothetical example I gave:
1. Nothing changes.
2A: Nothing changes.
2B: (Probably) nothing changes. (Debatable, but let's assume that.)
2C: iMessage passes the +123 456789 destination, a little meta data, and the message to an authorized message sending app/protocol registered to Apple's API (let's call this "WhatzzApp handler" for example), and "WhatzzApp" tries to send the message using its protocol. If successful, it returns a "sent" to iMessage for onscreen display. If unsuccessful/timeout, "not sent" back to iMessage to try the next registered messaging sending app (if registered). Loop, repeat.
Then you can do everything basic from Apple's iMessage UI, which obviously improves the experience for Apple's own users. If Apple wants another color code for these API handled message bubbles, fine, go for it. And for something fancy (like N-way audio or video chats) you'll probably still have to go to the individual app. But for sending a message, or picture, or video clip to another person, this'd be the way iMessage could do it.
Apple could set certain reasonable *mutual* requirements to play. For example, end-to-end encryption.
Again, what's wrong with this? This is how messaging apps like Pidgin/Adium have worked for 20+ years: with protocol handlers (plugins). Why isn't Apple improving the messaging experience for its users in this way? It sure seems like it could, and quite easily.