I just tested this. It only works if your iPhone is not set to display messages in a larger font. It also does not affect OS X's Messages. It also is not a problem at all for blind people using VoiceOver.
Therefore, the most logical hypothesis to me is that it is indeed an error with text wrapping - the bubble is just a hair too narrow to display the last word, and it's being wrapped, but the bubble isn't being expanded vertically.
WARNING: propellerhead content ahead!
As a software developer, I will wager my guess on this one. I'm guessing that the width and height of the bubble to be displayed is computed based on the text to be displayed. It's most likely floating point numbers are used for these calculations.
If you've done any development involving floating point numbers, you'll know that they can be a real hassle. For instance, due to the way floating point numbers are stored in binary, you cannot exactly represent the decimal number "0.2" or "1/5" as a binary float. This means that depending on how much precision you're expecting, trying to represent 0.2 in floating point might instead leave you with 0.19999999999999998 or something similar depending on the precision of your float.
You can understand this a bit if you think of the fraction 1/3. There's no way to accurately, exactly represent that number as a decimal number. 0.3333333.... will go on and on forever. So often it might get written as 0.33334 or something similar depending on precision. Since computers represent all numbers as binary, the fraction 1/5 produces the same effect and ends with a binary number like 0.001100110011001....
To solve this most code needs to use a "Delta" value, or basically an allowable amount of imperfection in the values. If you perform a comparison and say "is 0.2 equal to 1/5?" you will find that it's false. Why? Because remember 1/5 is actually 0.199999999.... and not 0.2!
Using a Delta lets us allow some imperfection. The question then becomes "is 0.2 within DELTA of 1/5?" Say the DELTA is 0.00001. We compare 0.2 and 0.19999998, and find out if the difference is less than 0.00001 - it is - so we decide these two values are equal.
But I digress. Suppose that iMessage computes, based on the text, that the width of the iMessage bubble should be 4.2 units and the height should be 1 unit. The type of units is irrelevant here - the important part is that at some point we're dealing with a floating point number.
Since we just learned that 4.2 can't be represented exactly, this will come out to be 4.19999998 or something like that. At some point, measurements have to be converted to an integer number of pixels. Depending on how the rounding works, this might get rounded down by one pixel from what was expected due to this floating point error. So now instead of drawing the bubble, say, 360 pixels wide, it gets drawn 359 pixels wide.
The bubble is then drawn at the size specified, and then the typography code steps in and tries to write the text into the bubble, but finds that the bubble is one pixel too narrow. It does what it's supposed to do and wraps the text to the next line, but since the bubble was drawn only one line height high, we don't see the second line!
No matter what the cause here, I can safely say that this is NOT in any way an attempt to censor content. The message content is there - VoiceOver proves that. This is entirely a GUI bug and I'm sure it will be addressed.
In the meantime, you could make your text a bit larger. In Accessibility under General in settings, you could set it to one size up - 20pt - and all of the phrases we've discussed here show up correctly. (Of course, if my theory is true, there's probably other phrases that can trip up ANY font size!)
