I think Ashley Nolan has the right idea here:
Many posts on PostCSS compare it’s features to Sass equivalents, but PostCSS doesn’t have to be used as an alternative to Sass. It can instead be used to add additional features to your workflow that Sass doesn’t provide. … These extra tasks can run either before or after your Sass compilation, as PostCSS can parse both SCSS and CSS.
PostCSS has proven to be much easier for developers to write add-ons for. There are tons of add-ons that are highly compelling. But I think it would be a mistake to pick out, say, a dozen add-ons trying to replicate what what Sass already does, in addition to the others you find useful. Your CSS code base risks becoming this weird highly customized syntax – you’ll be coding on an island so to speak. Not to mention at the mercy of untold third-party maintainers.
I think the trick is to use Sass (which has so many strong battle-tested syntax choices over the year) and sprinkle in PostCSS processing with good add-ons. Good, meaning actively maintained and that don’t mess with the language. I prefer add-ons that have a familiar looking syntax, but it’s invented, so it will never awkwardly conflict with current CSS, future CSS, or other preprocessing.