But I could see this being a performance hotspot - looping over rows and tallying a running sum across many accounts seems like a waste of cycles.

What's the alternative to the "what was the balance at date/time" in non-ledger based systems?

Consider the example database state in the article:

Transfer ID Description ┃ user receivables available 1 order created ┃ -$10 $10 2 payment received ┃ -$10 $10 3 partial refund ┃ $5 -$5

A real application cannot go very far with this kind of "description": every type of transaction needs specific data, whose complexity dwarfs the double-entry ledger mechanism.

For example "order created" transactions need a reference to an order with details of what has been ordered, "payments" need a reference to a collections of debts that they are meant to pay and details of how they have been paid, "refunds" are actually many types and need a reference to what they are refunding.

Real accounts are also much more complex than a history of changes and a computed balance: for example, some of them need to be included in accounting calculations and reports in various roles, with largely arbitrary relationships and accounting criteria, while some are linked to real-world persons.

Comparing the two ledger implementations that the article references is instructive: Pgledger has simple ID columns for accounts and transfers, and it is up to the application to use them as foreign keys from the interesting tables, while TigerBeetle also offers some generic "user data" and "code" columns with arbitrary data and suggests having a separate "control plane" database.