I think you underestimate how painful wrangling the proliferation of chat apps can be!
Another application is resource-constrained devices. I love the netbook form-factor, but my little Intel N200 machine buckles under the strain of running what amounts to six web browsers simultaneously (because everything is Electron now) in order to receive notifications from all the chat networks I have people on.
It can also be nice to have a kind of buffer layer in between you and the chat network, which doesn't necessarily have your interests in mind. For example, Facebook Messenger's Android app somehow managed to wake up my phone's screen every time it received a notification, despite my turning off every related setting and permission I could find. So I put it behind Beeper and the problem is gone.
that FAQ is accurate but (rightly) doesn't cover high-security deployments.
if I'm running the bridges local-to-the-client (I am, on my McBook) it's not meaningfully any less e2ee. encryption happens in the matrix client (running on the laptop), the encrypted message is sent to the homeserver on localhost, the bridge (on localhost) grabs the encrypted message and decrypts it, then the bridge re-encrypts it and sends it to Whatsapp (or wherever). the content of the message is as secure over the wire with this approach as using first-party apps directly
if one hosts their own bridges they're person-in-the-middling themselves and should take all the necessary precautions. if they're using beeper's hosted options they have to delegate read/write ability to beeper (though I think the signal and imessage bridges might be device-local), and beeper is clear about that.