The problem here is the basic assumption that the Tika facade class makes about how the configured parser will use the instance passed in the ParseContext.
By default (and before we added the constructor that allows a custom parser to be given) the Tika facade will construct and use an AutoDetectParser based on all the available and/or configured format-specific parsers. Format-specific parsers that support embedded documents expect the ParseContext to contain a parser instance that they can delegate parsing tasks to, so to support parsing of embedded documents the Tika facade passes the configured parser instance through the ParseContext.
The ForkParser on the other hand assumes that anything in the ParseContext is serializable so that it can be sent to the forked JVM process for use from there. Passing a ForkParser instance to the forked JVM like through the ParseContext could easily trigger a recursion of new JVM forks being created, which is why the ForkParser by design is not serializable.
I agree with Nick that the resulting error message could certainly be better, but I don't it's a good idea to change the basic design of either ForkParser or the Tika facade class in this respect.
If we want the Tika facade class to support forked parsing, I think it would be better to add a separate flag for that to explicitly make the facade class create and use a ForkParser instance based on the configured normal Parser instance. However, the ForkParser is a pretty complex tool that practically always needs custom configuration (java command, memory limits, class loader, etc.), which is why I don't think we should expose it through the Tika facade that's mostly designed for simpler use cases.
PS. Instead of the instanceof check we now have in ForkParser (thanks for that, BTW!), it might be a better idea to check for errors from trying to serialize the ParseContext. That'll capture a muhc wider range of cases where a ForkParser instance or some other non-serializable resource is being passed to a forked JVM.