1. Data caps are now the norm. A service that streams video 100% of the time is swimming upstream. OnLive would also need to recoup the significant costs of an uplink capable of serving all its customers full-HD streams. Typically a video service heavily uses a CDN (think Akamai) to only upload a few streams and then have the CDN push those out to edge servers. OnLive needed enough bandwidth to be its own CDN. And cellular data is an even thornier problem in terms of reliable throughput AND latency, which both have a direct effect on OnLive's service.
2. Game Studios are famously protective of their high-value assets. OnLive needed to convince some AAA studios to do a new release of their titles on its service. Engineering the games to work well with OnLive isn't the only problem here: it would be easier to be wholly acquired by a big studio than to convince anyone in the industry to do a deal that fit OnLive's marketing. Game studios want to see big up-front profits on opening day. OnLive's marketing was more along the lines of a trickle of profits over a longer term.
(Yes, they had some titles, but they needed bigger ones.)
3. The OnLive marketing about enabling some amazing capability (like cinema-quality graphics or breakthroughs in AI) swims upstream against what the "cloud" is supposed to offer. An OnLive session for one customer takes several machines, while the "cloud" basically makes money by stacking idle VMs so it's many customers to a machine. The only way OnLive would make money is if everybody rented the AAA title and nobody played it.
There is some really interesting tech in that space, but those are some basic problems with what OnLive was trying to do.