I found this article which present a compelling case against Sass:
meiert.com/en/blog/no-css-preprocessors
His case:
I don’t feel the problems CSS preprocessors intend to solve are serious enough to warrant the cost, either, and to me the solution is worse than the problems as well.
I want absolute control of my CSS and work directly on it, too, and likewise see exactly what will be sent to the browser before it’s getting minified and compressed. (In this list I don’t care too much that parts of the concerns may be addressed through better tools in the future.)
I don’t want to learn and depend on a non-standard syntax to wrap my CSS in, either, neither would I want to learn several syntaxes, and again neither would I want my teams to.
I want my source CSS to be deployable at all times, too, and if any build processes fail I equally like to be able to deploy the source CSS as an emergency solution.
I don’t want to have to wait for compilation before seeing the results of CSS changes, either.
In addition to these points, I could always mirror preprocessor functionality through languages like PHP, just like Bert Bos had brought forth as a main argument against CSS constants.
The only exception to me, and there I disagree with Roger, is that we don’t only need but can actually have pretty DRY CSS without preprocessors. Not repeating ourselves should be first nature to us, a part of our craft, and as we can’t yet automate DRYing up CSS it’s on us to keep our style sheets efficient and maintainable.
I find it a nice addendum to Jason Knight's already compelling argument.
As for me, I've been practicing grouping selectors as I go. I find it perfectly feasible to skip Sass at this point, at least in my case.