Also, while it looks great, usually its very difficult to integrate this header, without breaking existing JS functionality. For example, if you set this header, inline JavaScript will not be executed, this includes added event methods directly on DOM elements. Also eval() and writing setTimeout() and setInterval() like:
window.setInterval("alert('hi')", 10);
Are forbidden from executing as well. Finally, using 3rd party libraries (Mixpanel, Google hosted libraries, Intercom.io) becomes nearly impossible without explicitly whitelisting domains in the header (a huge hassle to maintain).
edit remember that the support of 1.1 is relatively low and incomplete as the webappsec group is voting on whether moving it to WD (working draft or not). So for cross-browser compatibility, you are still better off with 1.0 which is at this point very stable in major browsers.
I definitely see it as being the biggest roadblock for most sites. The report-only mode is useful for getting a work list of what needs fixing.
Plus long term moving inline JS to separate files must improve maintainability, version control, and also means your caching might work more effectively. So there is a little gain for the pain (aside from just the content policy).
"For example, if you set this header, inline JavaScript will not be executed, this includes added event methods directly on DOM elements. Also eval() and writing setTimeout() and setInterval() like: window.setInterval("alert('hi')", 10);"