There are two reasons for breaking down an n-way tie into its binary components:
1. When not all parts necessary to build the relationship that the tie represents arrive synchronously. Let's assume there is a relationship (customer, order, invoice). In order to populate this 3-way tie all information must be known, but it is not unreasonable to believe that the invoice is produced some time after the customer has made the order. It may also be of importance to track customer orders regardless of if they have yet been invoiced. In that case it is better to decompose the relationship into its binary counterparts (customer, order), (order, invoice), (customer, invoice). The binary tie (customer, order) can then be populated immediately after a customer has placed an order.
2. When you have complex cardinality constraints. Again, assume (customer, order, invoice) and the constraints that a customer may make many orders and an order can only belong to one customer, but an invoice involves exactly one customer and one order. In that case order should be "many" with respect to the first constraint, but "one" with respect to the second. Theoretically, this is not a problem for the 3-way tie, but such constraints are not practically supported in most database engines. Therefore, if you want the database to ensure the constraints, again decompose to (customer, order), (order, invoice), (customer, invoice). For these binary ties, the cardinalities can be implemented in the database as primary keys.
Still, I would argue, that if none of the above apply, an n-way tie increases the readability and understandability of the model better than its binary counterparts.