Problem is his model is primarily going to be microtransactions, the thing we are not catering to in 2.0.
Well, his application requires payment channels between a specific sender and receiver. You aren't going to pay Bitcoin fees on each tiny chunk of data. You only need to pay a fee once to set up the payment channel and then another fee to close it and settle the payment. Still, Bitcoin fees are considerably less than the default fee we would be targetting for typical transactions on BitShares 2.0. But there is no reason more creative fee models couldn't be used for other transactions to make micropayments like this reasonable.
First, I think we should absolutely have a min fee, max fee, and percentage fee for transfer operations. For example, transferring X BitUSD from one account to another could charge 0.001*X as a fee converted into BTS through the fee pool, but with a lower bound of $0.005 worth of BTS and an upper bound of $0.50 worth of BTS (if there was no fee pool or set fee exchange rate, the system could default to some fixed value like the upper bound). Blinded or stealth transfers will have to assume the worst case, therefore it makes no economic sense to charge less than the upper bound (which is also why the upper bound is so low, because otherwise stealth transfers would be unreasonably expensive for regular payments).
Second, setting up a micropayment channel would take a very small fixed fee (just to compensate the network for processing the transaction and prevent spam). But for the settlement transaction on the micropayment channel to be valid, it would require an appropriate fee to be paid depending on the amount of the balance going to the recipient (using same formula as regular transfer discussed above).
Here is an example. Alice sets up a micropayment channel from Alice to Bob and initially allocates it with 10 BitUSD. The micropayment channel expires at midnight of that day (3 hours in the future) and is set up to require a 30 minute refutation period. Setting up the channel cost Alice only $0.005 worth of BTS. If no one provides a valid settlement transaction on the micropayment channel before midnight, then the first valid settlement transaction on the micropayment channel added after midnight gets immediately applied. Otherwise, when either Alice or Bob submit a valid settlement transaction on the micropayment channel before midnight, the blockchain waits for 30 minutes (or until expiration time, whichever is sooner) before applying that settlement transaction unless the other party (Bob or Alice, respectively) submits a valid settlement transaction that is more recent (based on sequence number in the signed transaction) than the previously submitted one (in which case that settlement transaction is applied immediately). Each party only gets to submit a valid settlement transaction on the micropayment channel once (and they can even be free assuming they are standard ones that are small in size). Part of being a valid settlement transaction is to account for the fees that need to be paid which depend on the amount of the balance that is allocated to the receiver (in this case Bob). So, if Bob submits the valid (signed by both Alice and Bob) settlement transaction that pays Bob 4.30 BitUSD, it must pay a fee of at least 0.0043 BitUSD converted into BTS and the remainder of 5.6957 BitUSD goes back to Alice. In this case, the total fees paid by Alice are $0.0093 worth of assets for a net transfer of $4.30 worth of assets to Bob. There would still be an upper bound on the percentage fee, so if the micropayment channel was set up with a much larger balance and at the end the settlement sent more than 500 BitUSD to Bob, the fee paid would be limited to $0.50 worth of BitUSD converted into BTS via the fee pool (for a total fee payment of $0.55 worth of assets by Alice).
So we can totally make micropayment channels economically feasible on the BitShares blockchain. In fact the BitShares blockchain is so much better for this torrenting application because you are not going to want to wait 10 minutes to get confirmation that the micropayment channel is set up before sending the data (but with 1 second blocks on the other hand...). It's only problematic when you want to send a lot of small transfers to many different people (that you haven't already set up channels with a priori) where the amounts sent are so small that the minimum fee we are willing to accept ($0.005 in my examples above) is not quite low enough.