A (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document.
I think that restriction is implicit in the XSL Recommendation, because fo:instream-foreign-object , has the requirement that its child be from a *non-XSL* namespace. If the rec intended FO documents to be processed recursively, they wouldn't have had a non-XSL namespace requirement (i.e., why bother to require users to have a <finn:fodocument> that would just wrap <fo:root/>, if you can just use the latter tag directly?) Indeed, this restriction could be an argument *for* using ThreadLocals.
No, not really.
ThreadLocals should be used for storing data that is local to each thread (thread singletons). They are not a way to introduce global variables which just so happens to work in tomcat.