I actually think it might be even more performant to use cached CharBuffer's as they don't need resizing (once they're at their desired size) and can be easily reused.
Speaking of cached objects, we also need to take the concurrent access to the FieldMap/Message classes into account. So we either need to make the using methods thread-safe or clearly document that they are not.
A pre-allocated StringBuilder doesn't need resizing any more than CharBuffer does, except it will resize if it needs to.
Instead of using StringBuffer or StringBuilder, I suggest using the interface Appendable. This supports either, or a wrapper for CharBuffer or ByteBuffer (Given most FIX messages are ISO-8859-1 compliant i.e. don't need char anyway)
I agree the documentation should state whether it is thread safe or not, but as suggested in QFJ-740 it is not thread safe now which might be confusing given it is using StringBuffer.
Peter, as you write "most FIX messages are ISO-8859-1 compliant"...
There have been requests in the past to allow international characters, so we should not block this route.
But yes, at the bottom encoding level we talk about ISO-8859-1 encoded chars which are bitwise identical to the raw bytes the FIX checksum algorithm is working on.
@Peter: nice article. 
http://java.dzone.com/articles/why-synchronized-stringbuffer