Persistent queues sit between the input and the filter stages in the pipeline. If the pipeline backs up then the queue can transmit the back pressure into the input and tell it to stop accepting events.
For a beats input the protocol allows that to further transmit the back pressure to the beat and tell it to pause sending events.
With a udp input there is no way to tell the source to stop sending events.
For a tcp input the transmission window should close, which would force the source to stop sending. I do not know whether it is true that a PQ does not protect data sent over TCP. It seems odd to me that it would not, but I have not checked the code base.
Once an event is accepted into the PQ the input no longer has to concern itself with it. When it gets from the filter stage to the output the DLQ comes into play.
In theory several output plugins could support DLQs, but I believe only the Elasticsearch output does so.
"failing to deliver the event to Elasticsearch" is a pretty complicated subject. This, and the threads it links to, might be helpful (or may just confuse you!)
If for some reason you are using an http output to talk to Elasticsearch then this may be useful.