They are explicit strategies to use any provided processor implementation. In our case it's about scripting processors. From other side Expression and MethodInvoking are some special cases.
Before there was no any ability to provide a processor implementation to these components: Splitter, Transfromer etc. It wrapped our processor to `MethodInvokingProcessor` through `MethodInvokingHelper` in the framework. And we should use the same technique in our applications, e.g. for `MessageTransformingChannelInterceptor`.
And that was why I pushed `createMessageProcessingHandler()` to subclasses of the `AbstractStandardMessageHandlerFactoryBean`.
I was thinking to introduce new implementations for these abstract classes, but they were looking very simple and redundant as their logic fully covered in the base classes.
I understand that it's more easier to review new code than refactoring of an existed one, especially if it looks working and legitimate. 
But as you may have noticed, this refactoring doesn't breake any tests and also it is some internal change, which won't break exist applications with almost absolute guarantee.