No; providing the ability to making the delayer's "dispatcher" thread transactional is completely orthogonal to the <request-handler-advice-chain/> implementation. If I had added that feature to the delayer, it would apply to the storing of the delayed message only, and nothing to do with dispatching the delayed message later.
Also, the <request-handler-advice-chain /> is not intended to make the handleRequestMessage() transactional, it is to add advices such as expression evaluating (after success or failure) against the inbound message - such as to remove or move a file payload; circuit breaker advice; retry advice. Of course, someone could add a tx advice, but that is certainly not the intent of the feature.
Note: I did not add <request-handler-advice-chain/> to the delayer; at the time, I didn't think it made sense. I suppose one could make an argument that a retry advice might be useful when using, say, a JDBC message store. If you think it's important, open a JIRA (or we can wait until someone asks for it). Note that, while merging, I changed your property to 'delayedAdviceChain' to avoid collision with the ARPMH superclass property (which is not currently exposed on the delay handler).