> A system which makes no distinction between any of these use cases and treats them all the same sounds very appealing to me
It's a bad compromise. If you want the cheapest transfers, you batch them. (This is the logic of Lightning.) If you want the most reliable transfer, you wire it. If you want to be sneaky, you use cash. (There are other reasons to use these modes.)
Batching being cheaper and slower than RTGS is fundamental to payment economics, irrespective of whether in an electronic database, armored car or blockchain. I go into this in a comment from about a year ago [1].
> That modern economics has programmed in accountability for slow, large payments doesn't mean the system wouldn't be better off if it changed
It's more fundamental than accounting. If a transaction costs X, aggregating N transactions into a single transaction reduces the per-transaction cost to X/N. The latter, batched process will always be slower and cheaper than the former.
(If a transaction costs Y%, aggregating bilateral transactions allows for "netting out," thereby reducing costs while increasing latency. For example, suppose Bank A sends Bank B $10, Bank B sends Bank A $5 and the Bank B sends Bank A $2. Real-time systems would see 3 transactions of $17. Net-settlement systems would see as few as 1 transaction for $3.)
Payments are generally batched because individual payments are slow and/or have restrictions applied, like time of day they can be sent or received, which are easier to reason about when aggregated.
If you remove these burdens by having a technology that is cheap and nearly instant for all payments, then there's no real need to batch.
We're not quite at cheap + instant with crypto, but there's nothing preventing it in principle. And when we get there, there's no reason batching needs to continue to be part of the equation, at least not with the same tradeoffs.
> Payments are generally batched because individual payments are slow
They're slow to enable batching. Fedwire is time-limited, but many other real-time payment networks are not.
> If you remove these burdens by having a technology that is cheap and nearly instant for all payments, then there's no real need to batch
Yes, there is. To make payments even cheaper. For any given transaction price and speed pair, there's a market that cares more about price than speed. You'll always be able to layer a net settlement layer on top of an RTGS network to serve that market at lower cost.
In any case, if we're arguing for RTGS, it will always be faster and cheaper to transfer money via database operations than on a blockchain. Fast and cheap are not–and should never have been–cryptocurrencies' selling points.
It's a bad compromise. If you want the cheapest transfers, you batch them. (This is the logic of Lightning.) If you want the most reliable transfer, you wire it. If you want to be sneaky, you use cash. (There are other reasons to use these modes.)
Batching being cheaper and slower than RTGS is fundamental to payment economics, irrespective of whether in an electronic database, armored car or blockchain. I go into this in a comment from about a year ago [1].
[1] https://news.ycombinator.com/item?id=16154956#16155708