One of the weird things about being a programmer is that we get really exposed to large crossings across orders of magnitude and it can be very difficult to internalize how that works. Sometimes, lots of little things
don't add up to something significant. I don't know the exact numbers, but it's not hard to guess that a cell phone, by the time it's done thermally limiting itself and dealing with a massively smaller cache and all the other disadvantages it has could well be literally only 1/1,000th as effective as a single dedicated machine running this stuff. At that point, it can easily be the case that a million cell phones might add only single-digit percentages of improvement to the system as a whole, which, for the amount of human intervention in question, is not a very useful result. (That is, the same amount of human intervention could be much more usefully spent; if nothing else, by installing the native clients.)
I'm not saying that's the exact number; that depends on a lot of things. My point is that this is a great deal more plausible an outcome than your intuition may think. (It could even be worse.)
A similar idea was in vogue in the oughties about loading JS onto web pages and having people compute things while visiting CNN or something. But especially on the much slower JS of the time, and with no access to GPUs, by the time you worked out all the multiplicative slowdowns involved, and dealt with the crazy broken communications topology (radically slower than in-memory bandwidth, etc.), you were looking at loading down millions of people's machines to get the equivalent of single digit high-power dedicated machines for all but very embarrassingly parallel problems. You were better off just buying the CPU power.
("Well then, what about Seti@Home and such?" All embarrassingly parallel problems running native clients, at high rates of utilization. That's a several orders of magnitude more efficient than running things when a visitor happens to visit some web page (terrible utilization), on a slow JS VM, in a single thread.)