I assume you’re asking about using a Map versus separate bins. If so, you have a cap of 64K unique bin names in the namespace. For most applications that’s just fine, but for some it wouldn’t be, for example if you generate time buckets for YYYYMMDDHHmm - you run out of those quickly if they were bin names. And right now it’s kind of a painful process to reclaim unused bin names for the namespace. If you use a Map it’s just a single bin names, and the server isn’t counting distinct Map keys.
There’s also less bin overhead being spent. Aerospike has no schema, so it’s flexible and you can modify the objects as you want. The objects in a set don’t have to be consistent, for example a ‘user’ set can have one record with an email bin holding a string, another record can have an email bin holding a list of strings, and a third record won’t have an email bin at all, as there’s no need for a NULL placeholder (by the way, this isn’t necessarily a great idea for your Java app 
). This means that the bin type information is stored along with its data, for each bin (see the Capacity Planning Guide). So a Map with lots of keys is cheaper in terms of overhead to lots of bins, though MessagePack has its own overhead.
The other advantage of Map and List is being able to deeply nest elements. You can still break up a Map into bins that are also Maps or Lists or scalar… it’s really up to you. Aerospike is flexible, sometimes too flexible, but you have different ways to model the data.
I and others have posts about modeling on the Aerospike Developer Blog. If you go to the Developer Hub there is a link to the Aerospike Summit 2020 training, which includes an 80 minute workshop I did about document-oriented modeling. I think you need to sign up for the Aerospike Academy, but the developer track content in the Academy is free.