Edit to add this tl/dr: A scalable private payments design derived from Zcash may enable new high-bandwidth applications including micro or mini-payments; but while I’ve brainstormed and am excited about the possibility, I don’t know if what I imagine is possible.
I still believe there’s an important under-explored design space at the intersection of L1 scalability, private messaging, and data availability.
For scalability, as much as we can restrict data to only being stored or transmitted between the parties that directly need it, the better. A counterexample is note contents and memos in current shielded Zcash: only the sender and recipient need to ever see those, but all nodes store them and they are transmitted to every current and future node (lots of duplicate bandwidth).
Meanwhile, for privacy, as much as we can restrict data to only being stored or transmitted between the parties that directly need it, the better. As a cryptography-happy crowd we’re often fine with ignoring this and just relying on cryptography to protect confidentiality, but another way to protect confidentiality is to just avoid sending the data to the wrong people in the first place.
So it really seems like there’s a deep connection between scalability and privacy to me, since achieving both involves limiting where data is sent to only necessary parties.
This is the kind of thing I have occasionally brainstormed about as a side-hobby. The last time around (a while ago) I had written up thoughts with the name Modular Scalable Payments Architecture. (I haven’t updated that since I last pinged you about it @earthrise .)
The key idea is “can we shift around data availability concerns safely so that data that only needs to be seen between specific parties only needs to be stored/transmitted between them and no one else”. It’s not an easy trade-off, because currently wallets rely on the network to store all their private baggage, which is great for restoring from a seed or storing-and-forwarding new incoming transfers to wallets that have been offline an arbitrary amount of time.
So the two big UX challenges with that approach are: (a) how can we ensure offline wallets can still receive transfers, and (b) how can wallets restore safely from backups?
-plus all the privacy and consensus challenges. 
However, if there were a good solution, then presumably it would work well for higher bandwidth p2p usage. If the storage/bandwidth for the overall L1 did not grow linearly with what users send to each other, and/or if the latency of those messages weren’t bottlenecked by consensus, then generic messages, media, API calls, etc… could be bundled together with transactions within the same (idyllic/unicorn) system.
That’s the dream.
ps: One other reason the idea excites me: a lot of the scalability research across the crypto industry is focused on general programmable systems without privacy. This is way harder!
General programmability means it’s not clear up front which parties need access, and a lack of privacy means there’s not even precision or clarity on who that is. For example, DEX last-trade-prices may be consumed by many completely off-chain actors!
By contrast, if we have private transfers from senders to recipients, the number of parties is relatively small and completely explicitly defined by the privacy constraints. So maybe the design space is much easier than the rest of the industry’s scalability goals.
So it may be that no one is looking at this particular niche of design space, and Zcash could lead in this niche. I would guess that layer 2 payment protocols, especially lightning are the closest in the use case and adoption here. (The idyllic/unicorn MSPA would not have the liquidity constraints that lightning has, which seems like a major advantage if a real unicorn MSPA could be found.)