I understand where you stand from, I've done quite a lot of work on support / upgrades of existing websites. I still think you may benefit from a workflow that uses a local build system... and once you use a build system, why not throw a preprocessor in?

I can give you an exemple of my workflow for simple websites using Gulp.js (I used to use grunt.js, but really, it's all the same)

I have a frontend folder structure that I carry around projects. There's a components folder and a build folder. The build folder is for minified files only.

The components folder is split between components of the website, a bundle folder and a common folder. So I have /frontend/bundles, /frontend/common and let's say, /frontend/core-navigation.

Under frontend/core-navigation, I have /styles (and scripts but let's ignore scripts for now). Under /styles, I have a main-menu.scss file. This allow me to have in there only the styles of the menu of the website. However, I don't want to burden this stylesheet with font-sizes, browser hacks, media queries definitions, etc.

That's where the /frontend/common/styles folder come into play. In this folder, I have a config.scss file. This is where the preprocessor really shines. All the reusable and common variables, styles and mixins are there.

Let's say $brand-color: #b41e3c; which is a blood red. Then, I have all the colors that starts from this color. The color for the titles of my website has to be the brand color but a bit lighter. That would be $light-title-color: adjust-hue(desaturate(lighten($brand-color, 20.58824%), .47553%), -4.28571deg);. Repeat for every color.

Then, I have my font variables, $text-font: 'pier sans', sans-serif; $light-weight: 300; $extrabold-weight: 800; $letter-spacing-normal: .05em;

I also have a bunch of mixins that are going to be used all over the website.
@mixin icon-bag-white {@include scalable-icon-mixin('icon_bag.svg', 'common', $color: $white);}
%hover-transition {transition: all #{$konstan-transition-hover}ms ease-out, z-index 1ms;}
%form-label {
display: inline-block;
font-size: rem-calc(11);
text-transform: uppercase;
&.required em, .required {
float: right;
color: $brand-palette;
}
}
etc.

My media queries are also all predefined. $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})"; which allow me to easily use mediaqueries this way: @media #{$xlarge-up} { /styles for xlarge-up/}

Back to frontend/core-navigation/main-menu.scss. Now that I have all those variables, I can easily style my main menu using the existing variables and styles definition that are in my config file. If I want to have a form label, I can simply @extend %form-label and I don't have to rewrite all those style definitions. I work in team with other developers, so it really help to have those definitions written only once so that we don't end up with code duplication.

All of those styles sheets are bundles under the /frontend/bundles folder. In this folder, I have multiple files filled with @import definitions. All those are bundles and using Gulp.js, I can output them wherever I want. Most of the time that's going to be under /frontend/build/stylescore.css. However, if I'm working on a CMS website, I can output the minified stylesheet in let's say, /magento/skin/styles.

I use gulp.js to minify my stylesheets, to compress my images, to generate multiple versions of my share icon for every device out there, etc.

Something really cool too is a task which write browser prefix and browser hacks for me. I simply write display: flex; and when I save the file, it's going to put display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; in the build file for me. There's one for polyfills too, so you can use rounded corners on IE7, etc.

All of my files are put under a watch task, so whenever I save a file, the workflow starts by itself. If make changes to main-menu.scss and save it, it's automatically going to minify the file and send it in the right folder. I can work as if my .scss file is a normal .css file. And the beauty of it? It's all done locally, no dependancy on a server or a backend guy. I don't need to install any php module on the server or anything. I simply throw the /build file on the production server and everything is going to work the way I want it to.

I have a similar workflow that use the same folder structure for my scripts.