A few reasons, namely more consistent performance long-term and FIFO/LIFO/etc.  I'm not terribly familiar with v8 yet but here's what I've gathered so far from the current RC.

stock.move transactions function almost exactly like accounting transactions, except there is no end-of-year closing system on inventory (that I'm aware of).  qty_available in 7.0 and prior is calculated using all stock.move transactions in history on that product, so as a result, performance would decrease at a relatively consistent rate.  More stock moves means more work for postgres to generate quantities.  In a large system that has been running for an extended period, calculating currenty quantity would mean aggregating years of in and out transactions.  account.account balance calculations address this problem with EOY closing/opening entries.  Calculating an account balance only means aggregating transactions as far back as the most recent opening entry, always less than a year's worth.

Quants aim to fix this by only representing stock that's currently available.  It's basically moving from O(n) complexity to (I'm guessing) O(log(n)).  As a product is sold and leaves the warehouse, the existing quant is adjusted and a new quant is generated for the customer virtual location (since stock moves are always double entry just like accounting moves).

For example, imagine 1 million WIDGETs purchased 10,000 at a time and sold one at a time.  With quants, qty_available needs to read 0~100 records.  Without quants, qty_available needs to read 100~1,000,100 records.  All of the heavy lifting is done within postgres so it's still reasonable, but over time performance will only decline.

This also makes quants perfect for enabling removal strategies like FIFO.  Quants actually care about WHICH units of a product are in stock, not just that there is some stock.  In accounting, nobody cares which specific dollar is spent, all that matters is that money moved from one account to another.  In warehousing, which specific product you're moving does matter because of expiration dates, negotiating lower cost prices, etc.  The structure of stock.move isn't really viable to handle logic like that.