I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.
I’ve documented my love for LESS on this very blog many times, but it’s good to see someone pointing out the potential dangers of using them: excessive code duplication and the performance hit associated with over-specific selectors. Be sure to read the full article first, then come back if you want.
Done? Good. Now I’ll ask you: are these problems with pre-processors, or with how people are using them?
If your only programming experience lies with CSS or HTML, then by all means do yourself a favor and stay away from pre-compilers. I know from experience how easy it is to get carried away with a new language. If you’re not careful you could quickly end up shooting yourself in the foot by overcomplicating things.
But if you have a good grasp of plain CSS, you know some object-oriented programming and you understand how your LESS/SASS code will compile to CSS… Why the hell not? You should never see potential abuses by some as a reason to dismiss an entire concept for everyone. Pre-compilers don’t write bad CSS, bad programmers do!
 Although unless you’re writing the next Google, Facebook or some other mammoth web-app, I don’t think over-specificity means all that much for performance unless you’re desperate to eek out a precious few milliseconds, of course. It has its effects certainly, but I see it more as a problem hindering efficient code re-use, than with performance. If you find it helps you organize your code so you can more easily find your way, I think it’s a fair trade-off: After all, CPUs will only become faster, while programmer’s brains are pretty much stuck at where they are now. You can always optimize and refactor afterwards, if need be.