I'm sure it wouldn't be a stretch to write an extension for Brackets that allows you to handle templates more effectively.
On another note, you'd be surprised how many people are still doing pure vanilla. Preprocessing isn't usually part of a beginners toolchain, you gotta learn the underlying part first before you start grafting on the preprocessors used in larger projects.
We've actually stopped using all pre-processor for everything we do for Segment.io[1] as well, and we're not beginners.
One of the biggest problems with them is that you immediately eliminate a huge portion of the people who are willing to contribute to your code if you select a pre-processor they aren't fond of. It's fine for app internals, but for sharing small[2] open-source[3] components[4] it's not a good idea—whether it's Sass or CoffeeScript or Jade or whatever.
The other problem with CSS pre-processors specifically is that they only work well with the monolithic app mindset. All of your CSS files inside the same `styles` folder, and all of them required by the "top of the monolith" `main.sass` file. Instead, using something like component[5] you get true dependency trees, so you don't have to go monolithic anymore. And trying to get Sass to work across a component-ized codebase is a real pain. Instead we use Myth[6] to "post-process" the built CSS.
Pre-processors are a leaky abstraction that comes back to bite you at random points the way all leaky abstractions do, and the ways are usually hard to foresee and thus hard to argue against when the benefits seems so clear.
The build script can handle each component separately and stitch the results together. Just because SASS/compass encourages a monolithic style doesn't mean it's necessary.
On another note, you'd be surprised how many people are still doing pure vanilla. Preprocessing isn't usually part of a beginners toolchain, you gotta learn the underlying part first before you start grafting on the preprocessors used in larger projects.