Honestly depends on how you structure the HTML and CSS. I've worked on some very, very large projects stretching across 15 subcontractors and we did not use css preprocessors. It wasn't even an issue really.
CSS is really great at cascading properly. Most of the times I've seen where people want to use variables could have been just as easily accomplished via inheriting from a top level style.
But I'm not going to sit here and tell you you're an idiot for using CSS preprocessors. They serve a purpose. They work. Yes they complicate things further but if it helps you deliver faster I'm not going to complain...much :)
What was done to ensure similarity of HTML/CSS across such a large project?
Quality across more than 1 subcontractor for ANYTHING is rarely good. But the most important thing when dealing with large projects divided with multiple groups? Ownership. You make one group own the design / CSS. Then when others change their CSS it runs through them for reviews but they also supply guidelines for being consistent, etc.
It's almost impossible to handle disparate groups without having centralized owners and people who create guidelines on how to do everything so it's consistent.
It wasn't that long ago that nobody used [the current big-name] CSS preprocessors. But site admins got along fine, and I certainly didn't hear many complaints.
To each their own, but I don't find maintaining a big site with 'regular' css unimaginable.
Apart from those who generated css dynamically. And those who hated the situation enough to create preprocessors to improve their lives.
"Before X people were ok without X" is a tautology.
No, it's not.
Sometimes new techniques appear without anybody feeling there was a problem in the first place.
Other times they appear after people struggle and curse their way without them.
"Before X people were ok without X" only refers to the first case, so it's not a tautology applicable to all cases before X.
E.g. people always struggled with webpage layout, and knew they needed a solution X to appear, even before an X emerged.
Using tables for layouts was once state of the art as well with no complaints. Things change, as do best practices. You can use inheritance to reuse values without preprocessors, or you can switch to preprocessors and use variables and mixins for composition. The question of which is better (inheritance vs. composition) is a personal one, I prefer composition.
If life was fine without preprocessors, then why did they see such rapid adoption?
I'm not arguing for or against CSS preprocessors here. I'm trying to point out that one shouldn't have difficulty imagining coding a site with regular css. It's every bit doable, it has been done widely in the past and it is in fact still done today.
In some cases - perhaps many - it's not ideal, sure. But when OP says that not using these tools is unimaginable, I see that as a lack of effort on his/her part into trying to understand the point of view of the people who don't use them.
If I was a LESS user and somebody said, "I can't imagine a case where you'd want that tool", I would scoff at them because there are plenty of examples out there (and in this thread), and their statement shows that they're really not even trying to understand my point of view.
If they instead said, "I can understand why you think you need that tool, but ..." then I wouldn't have a problem because they have made an effort into understanding my point of view (and they can at least imagine using my workflow in their head, even if they don't like the idea).
This may be pedantic - after reading OP's post again, it seems possible that OP wasn't being literal about the imagination thing. But that didn't occur to me at the time of writing.
Don't measure experience by how long someone's done things. Measure it by what they've done. It's that old quote about "10 years of experience, or one year of experience repeated 10 years."
I've also been following this individual. I don't tend to agree too much with what he has to say because my experiences are very different.
I met a dev at a meetup the other night as I was giving a talk on Elm. He's been doing web dev almost as long as me. He still does HTML with tables. He uses inline CSS. He's never investigated a preprocessor, and has never looked at Angular, Backbone, or React.
But he's successful, so, shrug.
So be wary of "appeal to authority" arguments. Yes, he's been around a long time. Doesn't mean he's right.
None of us are really right. Just weigh all the opinions and decide based on experience.
I'm too old and tired now to try to convince people I'm right and they're wrong. I'm more interested in saying "I think this is cool and here's why."
For the record, I think Elm is the future and you can pry Sass from my cold, dead hands. Those are just my opinions, and they may change. It doesn't mean anyone who uses jQuery and straight CSS is wrong.
We can only say that it's "holding him back" only if we can show that he doesn't get the same results as SASS users, in the same amount of time.
We think your path is the wrong way and will cause you problems as time goes on.
I don't care about mixins, variables, a few instances of duplicated code and my clients doesn't care about any of the code under the hood. In fact they care about time to market, and that is something I am exceptionally good at in my area.
In fact variables has always been possible with multiple class names.
The discussion about what we should choose between traditional CSS, SASS and LESS is on the same level as what color the bike shed should have. http://bikeshed.com/
Pick one and be happy, neither is better or worse. When you're building web applications, CSS is least of your problems.