As D.W. mentioned, the patent on OCB really is a killer; who would want to go through the legal hassle and expense of licensing OCB, when there are free authenticated encrypted modes available.
Another, considerably more minor issue, is that OCB does not support 'Additional Authenticated Data'. This is data that both the encryptor and decryptor provide to the mode; it is used to compute the authentication tag (along with the actual encrypted message). What this allows you to do is cryptographically bind the message to the message context; not only does the receiver verify that the message was not modified, he can also verify that someone didn't cut/paste a message that was originally meant in a different context.
You don't always need that; however, if you do need it, the only way to make it work with OCB is the put a copy of the context in the plaintext (and have the receiver verify that the context in the message is, in fact, the context that he expects). This is workable, but it would be cleaner if the mode supported it directly.
Update: the newer versions of OCB support associated data natively, but the patent situation remains "messy" at least