Ah, but the simple matter of fiddling with the sign has ramifications. You end up with people having to cram mnemonics into their heads like DEAD CLIC, and PEARL. On top of that, there are awkward limitations like a transaction having to work with exactly two accounts, one of which is debited and one of which is credited. The actual numeric deltas applied to the two accounts by the debit/credit can be any of the four combinations: UP/UP, DOWN/DOWN, UP/DOWN, DOWN/UP.
Under the sum-to-zero system, it's very simple. Negative-running accounts is what the system owes to the outside, including to its owners. Positive accounts are what it holds. It doesn't own anything: all of what it holds is either owed to its owners, or else to other creditors, so the sum is zero.
A transaction can update two or more accounts. The only rule is that all the deltas in the transaction add to zero.
That's as far as keeping balance is concerned: of course, the transaction has to reflect reality and accounting principles. For instance, if $1000 is injected into the business somehow (the company wins a lottery draw), that could be mistakenly applied as "+1000 cash, -1000 bank loan" which validates, due to summing to zero. But it looks like the company made a $1000 draft against the bank loan, which doesn't reflect what happened. The correct transaction is "+1000 cash, -1000 equity": the company is $1000 richer and so the owners have a greater interest: it "owes" more to the owners. (It's sort of as if the owners actually got the money, and loaned it to the business).
The debit/credit system's rule that a transaction must have a credit and debit of equal size also do not prevent bad transaction semantics: transaction from using the wrong asset or liability/equity account. It's just a gratuitous complication which provides exactly the same sanity check as summing to zero.
In my accounting system for self-employment, I have transactions that update four or five accounts. In double-entry, that would have to be done via an awkward series of binary debit/credit pairs. Moreover, I also have some "virtual" accounts: pairs of accounts that maintain precisely opposite balances that sum to zero. These accounts provide figures useful for reporting. For instance, suppose that transactions for receiving income are broken down: income doesn't go into a single lumped account, but some of it into "cash", some of it into "income tax withholding", and some into a third account like "health fund". But, for the sake of periodic income reporting, we need the whole lump together. For that, we can instantiate a virtual account pair "income" and "income-neg". In the same transaction, "income" receives the total, and "income-neg" the additive inverse of that to keep the ledger balanced. We can query the "income" account to see the lumped income, and not have to ferret that out of the income transactions.