I've looked into this before, and I've never been able to find an explicit rationale from Satoshi, but there are a couple of possible reasons.
For: Simplifies SPV verification
Imagine that rather than using the spent/unspent model, you track the balance of each address. You get a zero-confirmation transaction that pays to you from an address.
Now, to figure out what the balance of this address is, you need to get all of the deposits and withdrawals from it. If you miss one, you calculate the wrong balance.
You could fix that by forcing each transaction from an address to reference the last transaction by hash, but that eliminates an important property of Bitcoin - multiple deposits and withdrawals to and from the same address can be processed at the same time, without coordination between them.
For: Improves transaction privacy in theory
The change output (which you referenced as '8 BTC goes to Alice') is sent to an entirely new address, and in theory it is not possible to figure out which output is the change output. In practice, the real output is usually a nice round number, and the change output is something like 0.00019841.
Against: Makes increasing the fee really complicated
If you've used Bitcoin for long enough, you've probably run into a situation where someone sent you some Bitcoins, but didn't attach a fee.
If the change output were explicitly marked, the sender could just resend the transaction with a slightly smaller change output, and a slightly larger fee. Miners would know that they could safely accept the new transaction into their memory pool without helping anyone commit fraud. Then, we wouldn't need stuff like replace-by-fee or child-pays-for-parent.
Against: Makes the UTXO set much larger
If you have 50 outputs that make up your money, that means that you're taking up 50 times more space than you would if you had a single balance.
TL;DR: It could have been done differently, and there are some reasonably compelling arguments, but it's impossible to change now.
1You should probably point out that concepts like the UTXO database didn't even exist up until Bitcoin Core 0.8, it confuses a lot of people when they go and read up about "pruning" and wonder why the system we use today seems completely foreign. – Anonymous – 2015-06-25T02:16:37.740
1@Bitcoin They didn't exist because the idea was that the average person would use an SPV wallet. The idea that the average consumer or merchant should run a full node is a relatively recent invention. – Nick ODell – 2015-06-25T02:23:34.733
2The UTXO didn't exist because it hadn't been written yet, instead the client used an unwieldy and poorly scaling BerkeleyDB database. The current implementations of SPV are atrocious from a scalability and privacy view, so it's pretty irresponsible to go suggesting them to anyone. – Anonymous – 2015-06-25T02:28:35.673
1@Bitcoin Maybe I should rephrase: the idea of having a database of transactions and marking them spent and unspent existed, but it wasn't considered important to optimize the size of the unspent output set, because you can't serve SPV clients with just a UTXO database. WRT to scalability and privacy... this is probably getting offtopic. Shall we take this discussion to Bitcoin Lounge? – Nick ODell – 2015-06-25T17:01:44.987
"Against: Makes the UTXO set much larger" argument is only valid assuming that everyone uses only one address. Which means extremely bad privacy. – Jannes – 2015-06-27T22:24:26.787
@Jannes: possibly, but I'm not convinced that it's particularly difficult to link sets of transactions together by who sent them. And there are many circumstances where people use the same address repeatedly anyway, despite it costing just as much in terms of space in the current system. – Nick ODell – 2015-06-27T23:39:54.937