I'm using EWS Java 1.2, although 2.0 in C# shows the exact same issues, and Exchange 2010 SP3, so a particular bug in SP2 prior to rollup 3 regarding message bodies is not the problem.
Long story short: EWS + Exchange = pain. Using EWS in Exchange, you can create an Appointment. You can specify that the message body of the Appointment be HTML and give it a bunch of HTML to go with it. This will do some kind of HTML -> RTF conversion that wrecks the HTML when you view it in an Outlook desktop or web client. Okay, well, we can tailor the HTML to something that doesn't get eaten in the process and still looks decent.
Except that when you update the Appointment with a change to the message body, it REALLY eats the HTML formatting. It doesn't matter if it's the same HTML you gave it when it was created. The second save will destroy it, leaving little more than bold text, line breaks, and tabs. It's as if it's either displaying the plain text with a few small pieces of formatting or it's displaying a very stripped-down RTF from converted HTML. What's really maddening is that it only happens once you update the body.
The thing is, I've taken a look at these Appointments (and related MeetingRequests, which are mulched the same way) in both MFCMAPI and in EWS by checking the extended properties. When the Appointment is first created, only the RTF body is populated. The plain text and HTML bodies are null, the RTF is in sync, and the native body value is 2, which means it should display RTF. Okay, that makes sense.
On update, all three body types are present. The RTF is out of sync. The native body value is 3, which means that it should display HTML. I checked in MFCMAPI. Both the plain text body and RTF body show out of memory errors, but opening the property will show it correctly. The HTML body is present. There is ZERO reason that this should be happening according to the documentation. The Best Body algorithm states that if the native body property is populated, then that is what will be used and it's all done. Well, that's obviously not happening. If it's not getting that value for some reason, then it will go through a conditional chain. Well, the conditional chain shows that the HTML body should be displayed in this case. MFCMAPI agrees when the item exported as it shows the native body to be the HTML body. OWA will display it just fine. But Outlook 2010/2013? Nope.
I'm at my wit's end here. I cannot get desktop Outlook to display the body properly no matter what I do. It seems to be something fundamentally broken serverside, but there are no known bugs listed (aside from the aforementioned SP2 pre-rollup 3 issue, which isn't the case here) and I cannot find any documentation that explains why the update breaks it so badly. The best I've been able to do is set the pidTagBodyHtml directly on creation and have it broken from the start. At least that's consistent.
EDIT: I've implemented the RTF decompression algorithm to peek inside. Sure enough, the RTF message body for a new Appointment and the RTF message body for an updated appointment (in which the body was updated with a virtually identical one) are very different! Exchange is following two separate code paths serverside and it's breaking the body format! The only possible solution I see is to also implement the compression and formatting algorithms and manually construct a valid RTF body in the client, which isn't exactly a small feat.