That does not increase the number of independent transactions that can take place. You can't have multiple recipients: "this does not allow you to send micropayments at high speed to different recipients" And you can't have multiple senders. You just get to do incremental transfers.
In the end bitcoin needs to handle around 1,000 independent transactions a second to see widespread adoption and even 100,000 transactions a second is low for some use cases. NYSE for example peaks well above that.
Today. Yes, today that's the limitation. But don't confuse the current stage of development for the future product. When twitter launched it couldn't handle much, today it's got phone-network level stability. Bitcoin will get there too; and faster than you think.
You can chain microtransactions atomically, so with a star graph of payment channels you can route micropayments through a central processor without introducing trust - taking the number of channels from O(N^2) to O(N) in the number of participants. I imagine a dynamic network of payment processing addresses could be chained in the same way, in order to provide a verified path between two participants using different channel operators.
Multiple recipients are already a feature of the blockchain (one input multiple outputs) and you can make each of those payments as small as you like, just so long as the rolled up transaction is over a given amount.
BTW, this does not require the rapidly adjusted transaction technique.
An example of a company working on this issue is monetas.net, which has announced launch for December. Their solution is based on OpenTransactions, which adds a layer on top of Bitcoin (or any other payment system) that allows to perform much smaller and cheaper transactions.
In the end bitcoin needs to handle around 1,000 independent transactions a second to see widespread adoption and even 100,000 transactions a second is low for some use cases. NYSE for example peaks well above that.