It's not.

I figure that back pressure is really important for streaming - where it's quite normal to have disparate throughput capabilities between endpoints.  But Akka is not a nice high level way to handle streaming (this is why Akka IO is being replaced with reactive streams).  So we have iteratees for streaming.

This on the other hand is a high level API for handling discreet messages, which Akka is very good at.  In that case, it is the exception, not the norm that mailboxes might end up being full, and in that case, it's much easier to handle as a deployment concern, by configuring the right mailbox and strategy for what happens when the mailbox is full.

That said, outgoing messages here don't sit in an Akka mailbox when the client is slow at reading, they sit in a chain of flatMaps in a broadcast enumerator.... this could easily be addressed by inserting a buffering/dropping enumeratee in the pipeline.  I don't know that that's a huge concern though.

Anyway, that's just my thoughts.