I see plenty of reason why you should embrace pre-processed languages, and I'll try to demonstrate the benefits of those tools.
1. Paradigm shift
In my opinion, the greatest feature of any pre-processed language is the ability you to develop and solve problems in a different mindset compared to the standard HTML/CSS/JS way. In short, pre-processing can lead to (but not always) a paradigm shift.
Why is it powerful ? Some problems are easily solved in one paradigm, some in another paradigm. What's powerful is that you can create any paradigm and convention that maps to HTML/CSS/JS to efficiently solve a particular problem.
The most known paradigm shift is made by C compilers, transforming easy to write C/C++ to efficient but hard to write ASM.
In theory, you could create a mapping between sufficiently complex CSS and JS, any CSS-aware designer could then use JS through well known tools.
2. Offline optimisation
You don't need to be pre-processed to shift paradigm, jQuery is paradigm-shifting at runtime. What's awesome with pre-processed tools is that the cost is (mostly) invisible at runtime.
Using compiled language compared to a library or a run-time toolkit is, in my experience, always better in term of final performance. This is very intuitive, if a piece of code is compiled once into optimised low level code without any dependency, it should perform better compared to the same piece of code executed at runtime by a library.
This is not new at all, compilers were the first (as far as I know) to introduce this kind of transformations and the first to introduce optimisations. This technique was proven efficient many time in the past in non-web environment.
3. Polyfill at the language level
The web world is browser based (boom! mind blown!), these browsers are updated and deployed at different pace, most web developers may have to deal with outdated browsers one day or another.
Up until now, many great libraries managed to fill those gaps for us. Yes, i'm thinking about the great mighty jQuery, many thanks to those who contributed to this awesome library. The problem is that library can only be written inside the scope of the language they're written in, and unlike in ruby, you can't meta-program everything in JS. Sadly, browsers still can't understand ruby.
This is applicable primarily to JS but also valid with CSS and HTML. To implement a new keyword or a new language structure (to solve problems faster, paradigm shift and stuff), you have to use pre-processing. Pre-processing sets you free from many kind of limitation inside the language, unlike libraries.
Want to use the new ES6 right now because your code will be more maintainable than ever? You can! Want to stick with your programming language and target a browser anyway? You can! (use emscripten).
4. Because we can (in a reasonable amount of time)
As the time of writing, compiling (SASS or Coffeescript in my case) is no longer a pain, it's instantaneous and can be triggered on file save with the right toolchain.
The build toolchain has evolved too, we see more and more great developer tools like bower, yeoman, gulp, ...
The frontend developer is now armed with a mature toolchain and is ready to tackle every common problem in a matter of seconds. Easy to install and maintain, your build tools and processes should be part of your project and should now be ready to accept a pre-processing step. (even if you only uglify)
Using compiled languages/tools is no longer a pain, and you should use any tool that fits your needs. The fact that it needs to be compiled shouldn't be a blocker.