Why do uncommitted transactions rollback instead of redo after a crash in ARIES? Since all actions within a transaction are idempotent in crash recovery algorithms like ARIES that use write-ahead logging why do we rollback after a crash during an uncommitted transaction to get back to consistent state rather than just re-doing the entire transaction?

This way we would complete the transaction and we don't need to deal with any undo.
Community wiki answer - please edit to add your contribution:

Generally speaking, there is no guarantee that an uncommitted transaction had actually completed everything it needed to do.

A transaction that withdrew $100 from BankA, but has not deposited the money in BankB is an uncommitted transaction.  If a crash occurred between those two processes, there is no way to tell what to redo because we didn't even get to the deposit part of the transaction which could also involve other calculations and updates.

An external application begins a transaction in code and runs several updates, inserts and deletes within that transaction.  Somewhere in the middle of that transaction, the server crashes.  Now, even if the database could replay and harden all of the updates that had happened up until the crash, how would the application know where to restart in its logic?

In a complete undo, you simply start the external application back at the beginning. The absolute safest way to deal with uncommitted transactions during crash recovery is to roll it back as if it had never occurred.

Atomicity - Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely, or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors and crashes.



In a properly-implemented ARIES - Crash recovery will start from a checkpoint (stored in master record), then it will need to figure out which transactions committed since checkpoint and which failed , then redo all actions and then UNDO effects of failed Transactions. See the answer to What happens when a DBMS crash during the recovery phase of ARIES algorithms? by Remus Rusanu. 

Also, remember that during crash "the contents stored in memory (RAM) are assumed to be corrupted or lost" so they have to be rolled back. Only the ones that are written to disk are valid / stable.