I don't know if the scheduling and privacy issues will be worked out anytime soon. But i can see some solid fiscal reasons why a company would want to use distributed cycles, rather than buy the computers for themselves.
CPU cycles have costs associated with them that a company with large jobs may not want to deal with. Computers take up considerable space, need copious air conditioning, and require repairs, and expensive staff to look after them (I know one portal company that is replacing it's U2's with quad boxes and better primarily because they don't have room for U2's anymore). They also become obsolete and depreciate. They also are static; these costs don't go away when you don't need the cycles.
So, total up these costs and you have an amount of money (say, $x) that the cycle user doesn't have to pay if the cycles are distributed. Split that $x between the owner of the distributed machines, the cycle user, and the organization in the middle, and everyone wins. The owners of the distributed machines would be doing all the repairs, housing, and so forth anyway, so they win. The cycle user can now rent or buy much smaller quarters and doesn't have to come up with the cash for the cycles up front; it can buy the cycles as they use them. Seems like a neat solution to me.
My main question is what kinds of money-producing computations can be done in this distributed fashion and not need results in real time. But i suspect that where there are accesible cycles, someone will find a use for them.
<PLUG>And if you want to sign up for ProcessTree, I wouldn't mind if you used this link.</PLUG>
The truth is rarely pure, and never simple.