It means you can write to any master, so your application need not be aware of "master" or anything. That's master/master anything, really. It just makes replication strategy transparent to applications and is far simpler to reason about. It's also far harder to implement on the server side, which is why most software you see that handles master/master (especially cross-DC master/master) comes with severe caveats, probably this included. Distributed systems are extremely difficult and come with lots of corner cases.

There's no reason you can't hang slaves off such a setup for various purposes either, I would assume, though I haven't used BDR and I'm not sure if that's supported in this software. The best replication strategy I've played with in general is a master/read slave setup in each facility with master/master between each facility. A lot of stuff is built that way, but most people never worry about datacenter failover so it's not the sort of thing you find on StackOverflow.

If I give you the knowledge that your Gmail inbox "lives" in one datacenter, imagine how you'd architect a backup for when that facility fails. That's where stuff like master/master starts to come in handy, because then you start thinking about things like "why would we build a backup facility and never use it? The user's latency to the backup is lower today."

If you have users in various locations, all of whom would like local access to a copy of the database.