1. Why was it important to separate CSS from HTML?
This meant that you had a choice:
Either you make proper separation between content (HTML) and style (CSS),
Or you mix both, either by putting CSS code within HTML files, or simply by using HTML analogs (
<div color="red">I'm red.</div>).
The first alternative gave you two important benefits:
No code duplication, which becomes valuable where you find yourself changing the color of a commonly used element from red to purple on every page of the website, making hundreds of changes in your code base instead of just one,
Reduced bandwidth usage (extremely important where most of your visitors have 56 Kbps internet connection), thanks to client cache,
Hypothetical ability to change style without touching the content: a point I'll discuss in part 3.
which also explains why so many personal websites were using
<div color="red">I'm red.</div> style at their beginning, and when becoming larger and more popular, were forced to migrate to pure CSS.
2. Why is it important to separate CSS from HTML today?
At development level:
Separating content from style may still be useful for the same reason as above: code duplication. If two elements share the same style, you shouldn't be writing the style twice: you should define it once, and then reuse it. Writing it twice leads to maintenance problems which are too obvious to explain.
Note that it doesn't really matter how are you storing content and how are you storing styles. Content would in general be generated by the web app based on (1) data from the database and (2) business logic, while style would be defined in a static form, would it be a CSS file, XAML, or something completely different.
This leads to the second point: how this content and style is served.
At client level:
Serving content and style and applying style to content may take different forms: maybe an ordinary HTML/CSS, maybe some complex solution involving AJAX requests, DOM, etc. The previous bandwidth argument is irrelevant here: not only most users have 8 Mbps or faster connections, but AJAX requests can be cached as well.
Instead, the choice of the alternative would be rather based on the ease of use of a specific solution provided by a specific framework, and how comfortable the developer is delegating this task to the framework.
Here's a story.
But as any magical tool, it had limitations. It worked well for small websites, and if one day, my grandma starts programming in C# and decides to make her personal website, I would be the first one to convince her that she should use bundles.
The story was different for more complex ones. What if I want to include LESS files? Well, there was¹ a possibility to do that, thanks to the excellent architecture of ASP.NET MVC, but this meant reading through dozens of pages of documentation and creating dozens of classes. I'm not sure why would I want to do that, when a bundle-lessn from scratch solution can be done in less than half an hour with fewer code to write.
Framework features are great and can simplify your life, but they can also be a limitation. Small, personal projects can benefit a lot from these. Large projects tend to rely more on custom-made solutions, which are easier and faster to develop than to extend the framework.
Imagine I have a great framework which does an excellent job of generating relevant styles for every page, managing cached styles, etc. This is great, because:
This can reduce even further the bandwidth: if I have 600 styles but only 30 are used on the home page, this means 570 styles less to send through the wire and to process by the client; chances are, my home page will appear a few seconds faster.
This can make my life and my code simpler, for example by removing the global state. For instance, if I know that a specific style should appear only on that page, I may let the framework figure out which selector should be used, without taking the risk of picking one which may be used on a different page.
Now, personally, I've never seen a framework which can do that, and the ones I've seen appear too limited while not making my life simpler.
Is writing plain CSS easier? I would say so. CSS has its weak points, but many of them are solved by preprocessors such as LESS and Sass. Being able to use features of LESS/Sass while letting the framework process the code into minified CSS is great. But I'm not sure today's tools are mature enough to move from this way of working to something more powerful and abstract.
3. Separation of concerns matters. Is it?
You were mentioning separation of concerns in your question, so I would like to highlight this particular aspect separately.
I see a lot of arguments about separation of concerns, most of which are (in my understanding) based on assumption that it is more often to change just HTML or just CSS and once as opposed to editing HTML and CSS in parallel. While this might be the case for small websites, my commit history shows me the opposite - I usually edit both HTML and CSS together. So instead of separating all HTML from all CSS I would separate each component from each other.
When you change HTML, you will necessarily change CSS in most cases. This is not like DAL/BL/PL, where you can, for example, swap database layer without affecting anything else. If you change content, presentation, often, will have to change.
For instance, you're adding a new button to an element. Not surprisingly, the element is now too small, so you need to adjust its width.
In theory, the inverse is not true: you're expected to be able to throw away all your CSS code, and do something completely different. Same content, different presentation.
When Microsoft released WPF (a technology which powers the interfaces of some Windows applications, making it easier than it was before to design interfaces and apply styles to them) and the underlying XAML (a language used to describe both the content of the interface—buttons, lists, combo boxes—and the style—rounded corners, fonts, transitions), one of the benefits which were highlighted all over the ads was the ability to style application independently of the content.
Microsoft even made a tool for that. It's called Microsoft Blend. The theoretical workflow of a team is the following:
Interaction designers make a wireframe of an application on a piece of paper.
Software developers pick this piece of paper and create, in Visual Studio (developer's tool number one in Microsoft's world), the different windows of the application, putting buttons, lists and combo boxes.
They then give the unfinished application to interaction and graphical designers who open the source code not in Visual Studio—they are designers, they don't use IDEs—but in Microsoft Blend, which shows them not the source code, but a pretty interface where they can visually change the visual aspects of the app: move controls, set color and font, add transitions and animations, etc. Meanwhile, developers finish to implement the features behind the buttons, lists and combo boxes.
We have here:
The same initial requirement: being able to change style independently of the content, with the ability to completely replace the current presentation with a different one.
The same constraint: if content changes, presentation will be affected in most cases and requires changes too.
While Microsoft did a great job with WPF and XAML, there is still a tiny problem: from time to time, when you need to change a style, you have to change the content as well, which means that the workflow of the team is rather:
Interaction designers make a wireframe of an application on a piece of paper.
Software developers pick this piece of paper and create, in Visual Studio, the different windows of the application, putting buttons, lists and combo boxes.
Interaction and graphical designers and software developers work side by side on the interface of the future application, ensuring constant communication, regular meetings, etc.
This is exactly what happens with HTML and CSS. In theory, you shouldn't touch HTML when working on style. In practice, you're constantly adjusting the markup when working on CSS, because:
Either a specific style is impossible with the current markup,
Or doing it with the current markup would require too much CSS code or produce a very unclean, difficult to maintain code.
When you change HTML too often when you're working on CSS, this may be a sign that:
The HTML code was not well done in the first place.
The HTML code was made "without styling in mind". Experienced programmers who know well CSS will produce HTML code which will be easier to style. Programmers who master HTML but know nothing about CSS will write code which will require a huge amount of changes.
As an extreme example, CSS Zen Garden is an interesting study case of what can be done with pure CSS, based on an unchanged HTML code which was originally well done.
¹ I believe LESS support is automatic in newer versions of ASP.NET MVC.