I believe the real difference between these two scenarios is that the IOException definitely comes from the current document being read while an OutOfMemoryError might be caused by any number of other things, many of which are not recoverable. Catching unchecked OutOfMemoryErrors, skipping the file, and moving on seems like something we don't want to expect our normal program flow to look like. Catching checked IOExceptions, skipping the file, and moving on seems more reasonable.
That said, I will concede that having an email with a header so large that it noticeably imposes on someone's heap should be quite rare. And, because of the way that Tika handles metadata, it all needs to end up in memory anyway – there is no streaming of metadata, it is represented as a bag of Strings. The hard-coded limit I think has some value as a stopgap in cases where a bogus file gets mis-detected, but that is a general problem not limited to RFC822 messages. It certainly could be decided to err on the side of letting all documents through, even bogus ones with potential memory problems, instead of being too conservative and not letting some valid documents through.