CSP is a little painful to use right now. With that said, the upside is huge, so hopefully the growing pains go away soon.
There are the expected problems with libraries like TinyMCE expecting to be able to apply inline style, and having to come up with your own Google Analytics snippet and whitelist, but there are deeper issues as well.
Version 1.1 lets you do path based matching, but v1.0 browsers (Safari) choke on that syntax and end up allowing nothing (instead of using the host part of the whitelisted URI). Older versions of Firefox used "Allow" instead of "default-src", while Chrome complains if you use "Allow". Unfortunately the only way to know which version of the CSP header to send is with useragent sniffing. It would be great if browsers sent a version # or supported CSP features in the request headers.
Finally, you'd think the report-uri functionality would be helpful to see if users are experiencing trouble with your site, but it falls short. Even if your site is coded perfectly, common browser extensions modify pages in ways that trigger CSP reports. Expect to be inundated with tons of noise if you leave them on. You'd think that the next logical step would be to filter them, but you're not given enough information to do so. If you have a default-src, all the report will tell you is that your default-src failed on one of your pages. It won't tell you that it failed because of an unsafe-inline, or because an image path wasn't in your default-src list, or because some browser extension -- completely unrelated to your site -- tried to mess with the perfect page that you delivered. All you know is that something failed. Fortunately it looks like file & line numbers will be added in CSP v1.1, but v1.1 hasn't been finalized yet.