Intuitive up to a point
The problem with parallel programming is that it adds a third dimension in which one has to think. It's no longer just data organisation and control flow, there is now also communication to think about.
The change in thinking that is required does not compare with the structure programming and OO "revolutions" which are just more convenient ways of thinking about the Von Neumann architecture.
Because parallel programming is inherently more complex than sequential coding, it is both easier to make mistakes and harder to track them down (especially timing-dependent bogeys that go into hiding when one hauls out the debugger).
One solution may be to reduce complexity in other parts of development environment - although this has already been tried in the form of the Occam language. In retrospect there was nothing wrong with Occam (once floating-point support had been added!), its sin was that it was not Fortran or C.
In my view the ideal solution for applications outside the number-crunching realm would be something similar to the swingeingly expensive G2 "real time intelligent system" in which it is remarkably easy to express searches that are executed as concurrent tasks. When I last used it (some 10 years ago) G2 was an interpretive system and so was not exactly suitable for number crunching.
Over and above issues with the development environment, there is also the challenge of developing parallel algorithms. At least in the fluid dynamics area in which I've worked, the "smarter" algorithms always came with an increased degree of data coupling - in space or time. Loosening the coupling between data elements would generally result in a loss of algorithmic efficiency.