Advantages of UTXO/blockchain approach:
- You don't have to pay to addresses that refer to accounts. Transactions can pay to unique rules or conditions that can exist only as the rule to claim a particular transaction output.
- Transactions are more independent in execution, not contending for access to the same account structures.
- All you need to know about a transaction is that it succeeded. There's no "additional information" such as the previous balance and the new balance.
Advantages of account/ledger approach:
- Accounts exist as primary structures and so can have properties, both persistent/configured and dynamic/reported.
- Transactions are more independent in formation, not contending for access to the same transaction outputs.
- There is no UTXO database to maintain and synchronize and attacks on the UTXO set do not work. (Though there are other ways you can defend against attacks of this type.) More sophisticated transactions can be supported without creating the risk of disagreement on the UTXO set.
Bitcoin's design naturally fits the UTXO approach. Transaction results are simple, and there's no need for account parameters.
That approach would not have worked in Ripple for a variety of reasons:
Because Ripple supports arbitrary assets, many of which can be worthless, there has to be a way for recipients to indicate which assets they'll accept as payment. This means something has to have that as a property, which requires an account.
Something has to issue those assets, which requires accounts to act as issuers.
Cross-currency payments can produce complex results, trying to map those deterministically onto UTXO operations is not a natural fit. Adjusting an account's balance is simpler than choosing UTXO's to consume and create at transaction processing time. Ripple's transactions could not have, for example, specified which UTXOs they'd consume because that isn't known at transaction formation time. (How do you know know who will offer the best rate when your transaction executes? If everyone competes with transactions hardcoded for the juiciest liquidity, the majority of transactions will fail.)
The more complex network state requires a more complex structure to ensure the network agrees on that state. Bitcoin's structure has no way to protect against UTXO divergence, which would be catastrophic, other than keeping transactions simple enough that a mistake of this type is unlikely. Ripple's more complex transactions need a powerful defense against divergence or small bugs in the code could cause catastrophic results.
Because Ripple transactions have more complex outputs, they tend to be larger. Ripple's approach makes it easier to discard transaction history because all you really need is the current status of all accounts and other persistent structures.
You can pretty much meet any requirements with either approach. There are ways to work around each of these issues without changing the approach. But it's often easier to start with the design that most naturally fits your requirements, rather than shaving and jamming to get a round peg into a square hole.