Two separate exception hierarchies separating possibly recoverable I/O exceptions from probably fatal protocol exceptions is the conventional approach. Mime4j previously used this approach. MimeException was switched to subclass IOException between 0.4 to trial an less conventional approach with the advantage of a more concise API.
At the very least, since this approach is unconventional it should be well documented.
The argument in favour of a single hierarchy is that it allows a more concise and maintainable API.
In use cases where the user does not care about recovery, at most a single catch is needed. This catch is a general java exception (as opposed to a mime4j one) so in many typical use cases, a single general (ie not library specific) catch or throws will suffice.
This approach has the disadvantage that the correct exception to catch in use cases when the user cares about recovery is not self-documenting. In other words, the API is less obvious for these cases. The user will need to consult the Mime4J documentation and catch then rethrow or handle the MimeException.
My estimation is that advanced users working at a low level are more likely to care about recovery whereas users working at a high level are unlikely to care. So I think that this approach is worthwhile.