A bit of a meandering answer to the question, and to answer a side question: fundamentally what is a scaling solution?
OP_CTV does not increase the block space. Transactions using generally will use more block space actually (although it need not be a large amount), and relay can be optimized to equivalent.
But scaling is more than just a block size increase. The lightning network shows this -- not just because of eliding intermediate states from the chain, and routing, but also because of latency. It matters for lightning that confirmations can come faster than 1 block. This is not a minor point; if there were another way that you could get sub-block confirmations but use more total chainspace, people would probably still want it. Important to note that redeeming a channel still takes a long time potentially -- you're trading less latency now for more latency later (HTLC timeouts are longer than a single transaction confirm).
So, that said, what does OP_CTV do?
OP_CTV lets you more efficiently use block space over time. Imagine if you have a block that is almost full, and there's space for just a few inputs and outputs (let's say 2 outputs). Previously, this would mean that space would go to confirming a payment to one person -- one change address, one payment.
This isn't very efficient because we're only paying one person!
With OP_CTV, a single marginal output can confirm payment to an unlimited number of recipients. So that means the efficiency for confirming a payment on-chain is now much better.
However, at some time in the future those still must be claimed on-chain, which means that overall average demand isn't reduced (maybe, in fact, increased).
But if you look at trends, not all blocks are full. Sometimes they are, sometimes they aren't. A not full block represents "wasted" bandwidth for confirming transactions. All blocks should be full.
By splitting the market, we create two different "fee bands", the fee band for confirming a spend and the fee band for redeeming a CTV output. This creates a much healthier backlog for Bitcoin.
This is indeed similar to P2SH -- before p2sh, you pay for data on spend, when you should only need to pay for it on redeem. p2sh is bytes-wise less efficient than non-p2sh. And p2sh can't emulate it because p2sh operates at the script level, not the transaction level.
So what are the core benefits?
- Improved confirmation throughput
- Lower Fees paid
- Lower fee-rate for top of mempool
- Business operators abstracted away from "chain weather"
CTV also jives well with protocols like LN by increasing the number of HTLCs a channel can hold, which has been shown in some research (citation needed) that the number of HTLCs increasing is critical to LN working well. CTV also makes it easier to bulk-open channels, which decreases costs for opening channels & can increase LN routing viability.
CTV also enables new kinds of non-interactive protocols, which can eliminate a transaction between "withdraw from coinbase" and "open lightning channel". This meets the "classical" decreased block space usage criteria. This includes a case where, With Schnorr signatures/taproot, it's also possible to have the sub-tree be elided in favor of a new transaction.
See https://utxos.org/analysis/bip_simulation/
Oh, and it does enable similar covenants to the MES Covenants, see https://utxos.org/uses/ for more on vaults, non-interactive protocols, etc.
To close, a different definition of a scaling solution:
A blockchain scaling solution is a technology which decreases how aware users are of the fundamental limitations of the underlying blockchain, assuming they have proper wallet software (e.g., lightning support, ctv, etc).
CTV eliminates a large class of cases where a user bumps up against chain limitations, and is therefore a scaling solution.
