Both PostCSS and SCSS belong to the family of 'CSS preprocessors'. Styled Components is part of the 'CSS-in-JS' family of plugin, including Aphrodite, Glamorous, and many more. So to answer these I'll have to give you the advantages and disadvantages of each family of CSS plugin.

Before I do that, I'd like to mention that PostCSS is the closest thing in the CSS world to what 'Babel' is in the JavaScript world - it parses CSS, loads plugins that apply transformations to your code, and manages these transformations. SCSS a preprocessor and can be loaded by PostCSS, but PostCSS has the ability to load a lot more than just SCSS :D With PostCSS you could manage SCSS and Less and Stylus code, plus other things - all in the same codebase together.

CSS Preprocessor Advantages

• using a preprocessor can help reduce overall code size
• using mixins (plugins) allows you to create small shorthands for common snippets you re-use often
• sometimes large chunks of code (like CSS animations) can be expressed a more simple instructions, and turned into the full-length code later

CSS Preprocessor Disadvantages

• often conflict with CSS grammar, meaning nearly every preprocessor (unintentionally) excludes, conflicts, or limits you from using certain syntax or features in CSS
• requires a build step (some people strongly dislike compiling an interpreted language)
• All of your preprocessor knowledge stays limited mostly to that preprocessor you learned, and doesn't translate well to regular CSS or other tools

CSS-in-JS Advantages

• lets you define a 'design system' and 'automatically' styles elements it finds according to your definition of what it should look like
• depending on which plugin you use, you may be dealing 100% with JavaScript and not actually touch CSS at any point. For some people this is what they want ¯\(ツ)\/¯
• since it's happening inside JavaScript tools, it's easy to send or receive code from other JS-based tools

CSS-in-JS Disadvantages

• often requires you to be using JavaScript framework or library in your workflow to be building your code, otherwise these plugins can't run
• some tools make it harder to style pseudo classes (:hover, :focus, :active, etc) or pseudo-elements (:before, :after, etc) or make use of smarter selectors like :nth-of-type(odd) , or add media query breakpoints
• Many tools ignore the 'Cascade' part of CSS and work by applying styles to the element's HTML style="" attribute, which leads to overly fragile styles (what if 2 plugins want to change the style="", all they see is what's there, not what's putting it there or why)

I've NEVER seen any advantages to any CSS pre-processor that couldn't be equally accomplished by simply knowing how to use CSS properly, easing up on the mental midgetry of throwing classes at EVERYTHING, and bothering to leverage your semantics and CSS selectors.

Which is how I end up with 12 to 16k of markup where people using CSS preprocessors, OOCSS methodology, and mind-numbingly halfwit bull like front-end frameworks blow 60 to 100k!

MAYBE if people stopped using hundreds of K of CSS spanning a half dozen or more files to do the job of 32k or less in one file, they wouldn't be diving for nonsensical pointless garbage like SCSS.

All I've ever seen it done is further enhance the ineptitude and ignorance of those who use it. I've NEVER seen ANYTHING done with them that couldn't have been done more efficiently and effectively without them, unless it was something that has zero damned business on a website in the first place!

Oh, and Tommy Hodgins that first claim under "advantages" in your post? I've never seen that one be true... at least not by the time the preprocessor finishes off vomiting up whatever mess it has the unmitigated gall to call CSS.

Don't even get me STARTED about the derpitude of doing CSS from JavaScript, which is why everything wrong with SCSS gets multiplied tenfold in PostCSS. Controlling appearance from JavaScript for anything more than an animation enhancement (which even then should only be a class swap to trigger CSS3 doing the heavy liftting or height as a bugfix) -- EPIC /FAIL/. Do not pass go, do not collect $100.

Even server-side, it's dubios -- the tutorials about PostCSS all showing examples that would be LESS code without it! The "custom selectors plugin" being the poster child for how PostCSS is in the same class of stupid as w3.css! What the blazes type of brain damage does it take to see an advantage in this?!?

Much like the idiocy of HTML/CSS frameworks, I cannot fathom how or why anyone would choose to use these systems apart from knowing so little HTML or CSS they are unqualified to be using either in the first damned place!

PostCSS and SCSS both are CSS Pre- Processors (means you write CSS code using some tool (PostCSS/SCSS) specific style and it will get converted to CSS after a build process ) .

Using CSS Pre-Processors give you a lot more functionality than writing CSS in traditional style (Like auto-prefixing of vendor specific classes, complex calculation inside classes, using Global/local variables, mixins, functions, nested classes .. a lot more ).

The main difference between SCSS and PostCSS is the light nature of PostCSS. Means SCSS installation always carries all the functionalities it can provide while PostCSS is more modular in approach and you add functionalities that you need only in form of PostCSS plugins. (Like you need Auto-Prefix add its plugin).

Here's a good overview of PostCSS with the problems it solves while compares to SCSS & SASS. ashleynolan.co.uk/blog/postcss-a-review