The strongest hypothesis on why this design was choose by the inventor was that it was an attempt at fostering privacy. If so, however, it was only marginally successful. True, it did slow down analysis by smaller parties, but probably not much for lager ones. That result is useful, but also problematic in that it produces a false sense of privacy.
Another hypothesis is that by habitually re-formulating value assignments methods of optimization could be developed. I think from the get-go there was some efforts to police up dust transactions and reduce certain values to zero. The author had some ideas about resource usage via Merkle tree pruning and such as described in the whitepaper document, but they were never really followed up on in later developments as best I can see.
I thought the current transaction design was a byproduct of creating a trustless system. It allows any new user to enter the system and check for themselves that every transaction is valid. If the system only maintained total balances (instead of specific spent and unspent outputs), then there would be no way for a new user to bootstrap their system without having to rely on a trusted source of current balances. That single trusted source of current balances becomes a point of complete centralization.