A single payment is better for both purposes. The transaction fee is relative to the size of the transaction in bytes, so a 1 KB transaction which pays a $0.10 fee is equal to a 10 KB transaction that pays a $1.00 fee, all other things being equal.
A typical transaction that pays a single other person will have a 4-byte version, a 36-byte outpoint (previous output identifier), a 73-byte signature script, a 4-byte sequence number, two outputs of about 33 bytes each---one for the payment and one for the change (8-byte value, 25-byte pubkey script for P2PKH)---and a 4-byte locktime, plus a few 1-byte compactSize uints for the variable-length fields. That's about 187 bytes total for one transaction and 1,870 bytes for ten transactions.
On the other hand, a transaction with 10 external payments will have the same version, same outpoint, same signature, same-byte-size change payment, and same locktime (about 154 bytes). It'll also have 10 payments with 33-byte outputs (about 330 bytes). That's about 484 bytes total for all ten payments, about 25% as many bytes.
What you call sub-payments (outputs) can't fail individually. When the transaction is accepted by a node, it checks the outputs to make sure they pass that node's validation rules. After that point, the only thing which can make them invalid is if you create a double-spend---another transaction which spends the same input as used in the first transaction.