The Lean Panda team have had long experience with Sass — in fact we have recently “formalized” our way of operating and structuring Sass projects with the release of BEMO.
Well, the analysis we've carried out here hasn't given us any practical reasons that might motivate us to switch to an alternative preprocessor.
In addition to the general “draw” in terms of the features they provide, I feel that I ought to make one further point in favour the Sass's team's approach to the release of new functionality, which is well summarized by the words of Hugo Giraudel:
What I do like with Sass is its conservative approach to CSS. Sass’s design is based on strong principles: much of the design approach comes naturally out of the core teams’ beliefs that a) adding extra features has a complexity cost that needs to be justified by usefulness and, b) it should be easy to reason about what a given block of styles is doing by looking at that block alone.
Also, Sass has a much sharper attention to detail than other preprocessors. As far as I can tell, the core designers care deeply about supporting every corner-case of CSS compatibility and making sure every general behavior is consistent.
Returning to Sass, we have had the opportunity to test the libsass engine on a range of projects that have now been in production for several months, and we haven't observed its having any particular problems compared to its older brother. We therefore feel inclined to recommend it, and are awaiting a solution that will let us make use of it inside Sprokets, Rails' asset-pipeline.
The cssnext project is certainly interesting: at least in theory, the idea of being able to write using CSS4 (or its standard) instead of having to invest in alternative metalanguages makes sense, and would offer a way of ensuring that the work put into it doesn't end up “dead” in the space of a few years. In practice, however, despite its many improvements when compared with CSS3, the concept of scripting — so fundamental to frontend projects of medium complexity — continues to be entirely absent.
As regards the management of the browsers' vendor prefixes, Autoprefixer has demonstrated itself to be the best solution available; far superior to mixin, in stile, Compass or Bourbon, which require more maintenance over time. We have used Autoprefixer with great success in conjunction with Sass both within Rails applications (using autoprefixer-rails) and on client-side projects (with gulp-autoprefixer). It now forms part of our standard toolchain.