Ahhhh, sorry, just went back and re-read the original error again ... "waiting for SQM(s) to flush to outbound queue(s)" ... combined with your new comments about RA moving (which I take to mean RA was not at the end of the log, yet) and DIST eventually stayed up ...
I seem to recall a similar issue at a past client (a couple years ago). The issue had to do with a bottleneck in RS processing when a larger-than-normal transaction was pushed through the system. While a reconfiguration of the repserver could have addressed that client's issue it was determined that the large txn would not occur very often (also, the client had limited resources for the repserver) so we just implemented a job to regularly check for a down DIST, and issue a 'resume distributor' as needed.