After looking at this further, increasing the redelivery times had a lot to do with it. -- I believe with low redelivery times (default is 0ms) there is less chance for scheduledReferences to exist. With a high redelivery time (I was using 15000ms) I was consistently falling into the while() block and the filter match check.
Too early to tell, but adding "filter==null ||" to ScheduleDeliveryHandlerImpl and using a high redelivery time seems to be working for my "shutdown during activity" test case. I was having issues where messages in-flight during a server shutdown commonly ended up in the DLQ (because EJB was shutting down) rather than back in the input destination. I am trying to keep the redelivery logic from getting to the failed state for the server shutdown case.
One undesirable issue I found with using higher redelivery times is that returning, polling clients do not always have messages immediately available. It seems that the break in communication between polling intervals takes the server down the redelivery delay path. I think I would be happiest if I could find a means to shutdown message delivery and still allow message sends before/during EJB shutdown.