Those are solutions for very different types of deployments.
BDR is asynchronous multi-master, without global transaction management etc.
XL is a distributed database with global transaction management, strong consistency, etc.
Say you have geographically distributed application (managing customers in US, EU, ...). You can deploy a node in each area and direct local users to this node with low latency etc. It also means "no conflicts" (which is a major concern in multi-master), and the changes will asynchronously replicate to the other nodes.
XL would perform poorly in this scenario (at least I believe so), and it's meant more for local deployments, when hitting vertical scalability limits.
I use on it to keep my postgres data in sync in a high available setup. I host two nodes, each in a different DigitalOcean datacenters (AMS2 and AMS3).
It's fast enough to not notice delays for users. As in, have a user log in on host1, switch the user to host2 and the session is there.
Disclaimer, we're not write heavy and have around one hundred active users.
If you're interested, I'm trying just this over the weekend. Standard streaming replication over WAN was pretty awful. It would work reliably for a few weeks then cause both the master and slave to block writes when they got out of sync because something was dropped.
