Both. Or more precisely:
1 - it invited devs into a world of relatively high parallelism when many would have still preferred just better single threaded performance, even if the latter wouldn't have the same legs. Most devs at the start of this gen didn't really know how to exploit this much parallelism. It came up a fair bit early in the generation about whether Sony (or MS for that matter) would have been better off with just a typical dual-core intel, if the potential performance gains once people wrapped their head around Cell were worth the sweat etc.
2 - the spus threw out lots of programmer 'comforts' (something had to give to pack 8 of them on there), leaving some performance pitfalls for the unwary programmer - e.g. poor branch prediction, a memory model that required careful attention etc. They are quite fully functional - they can manage themselves independently, you can throw c code on there and it'll run (even if not necessarily very efficiently), but to get the best out of them requires care. Makes it difficult to just throw anyone onto SPU coding (e.g. a junior programmer), reducing engineer mobility etc.
3 - there was asymmetry, two types of processor, which reduces code mobility to some degree etc.
Developers have, I think, been getting more used to the idea of parallelism, so hopefully that won't be as difficult a curve on the higher parallelism of next-gen systems. I don't think devs 'hate' Cell anymore, I think some of the more ambitious ones may in fact love it now they can see what kind of performance is possible with SPUs (judging by tech presentations...third party ones too). But I can also understand why some devs, particularly 5 years ago, were sort of appalled by it.
