Well, the way PostTo was implemented is kind of interesting in that regard. I'm going to go at a complete tangent at this point, so feel free, who-ever is reading this, to ignore.
As far as messaging and bulletins, instead of them coming from the App or the App's Profile (since the App itself is a MySpace user, and can send messages, friend requests, comments, and bulletins just like a user, this would have been a viable option), they come from the person using the App at the time (the VIEWER). This makes sense for bulletins, of course, since if the App sent them, only the App's friends (likely only the developers) would see them; for messages it's possibly in the developer's best interest as well, since virally speaking, a person is more likely to read a message from a friend they know then from some random App they don't.
But, that also means messages sent through PostTo don't count against the App's sending limit, but the user's sending the message. It also makes Spam filtering on the recieving end harder, since all the reciever's profile ever sees is a message coming from a friend they (presumably) trust. Now, the MDP and MySpace have implemented some security features in that regard; a user can block all Apps from seeing them at all (which means they never appear in the Friend Picker UI widget -- a required part of the current PostTo interface), prevent Apps from sending them messages (I suppose by just blocking the FriendPicker widget from seeing them, but I haven't really tested out or seen that security measure in action), and by preventing PostTo from sending messages to anyone who isn't a friend of the sender. Also, previous spam filtering is supposed to work seamlessly with PostTo, such as requiring a CAPTCHA check before sending a message (again, a receiving-user setting).
And that's where you run into trouble with RESTfully allowing messaging. Because the javascript implementation requires some MySpace JS widgetry, and the security is built into the widgetry (including blocking messaging and handling CAPTCHA), it's not something easily duplicated RESTfully, at least, not in a way that would be easy to bypass.
Of course, sending messages directly from the App would fix that on multiple levels -- first, users can block them easily (through the spam filter settings currently available, or through a new setting that blocks all messages from App Profiles in the same way they can block them from Band and Group profiles), and second, it's much easier to implement, or rather make use of, MySpace's built-in messaging limit (there is a limit, and MySpace charges you, I believe, if you cross that limit). This would allow for easier management of RESTfully generated spam, as well. But it does have drawbacks. Obviously, app developers would prefer their messages get through, and since it's unlikely that even installed users will also be friends to the App's profile, spam filtration will become a problem (it's already been reported as a problem just for App User Support). There's also the problem of malicious usage in reverse; that is, an App User intentionally spamming with an App just to run up the App's message count.
Personally, I kind of like the fact that PostTo uses the VIEWER, not the App, because I like the idea of Apps that make spifier messages and comments (my very first question on these forums was about posting comments with an App - my intention being to design a better UI for adding comments, similar to the UI used to post blogs, but I'm digressing), but obviously, it does cause problems for externally-based Apps.