You don't _have_ to write CSS well to get it to work. People wouldn't follow naming conventions, wouldn't group common components near others... some people didn't understand CSS precedence and it could lead to incredible confusion, spaghetti code and extra work. Often people re-implemented functionality that was present elsewhere. And problems were exacerbated with sass.
From my perspective, tools that prevent people from writing additional CSS code will have a niche to fill for the foreseeable future.
It lints and validates the styles written and does it ruthlessly.
But, especially with CSS, I really don't see the value provided by a framework. CSS isn't hard to learn or master! And as OP suggested, doing so means you get more done with less code.
I know a guy who set up a project with a framework. He had a nice scaffold of the project and was amazed and overjoyed with what he had done with so little effort until it was pointed out to him that he had 40,000 files in a project that didn't actually do anything. Much less solve the customers problem.
And you're wrong. CSS is incredibly hard to maintain. It easily becomes an append-only list of rules. Medium.com for example hired a team a CSS developers including a co-creator of Bootstrap just to work full-time on its CSS.
This is a good example of developer hubris and the HN trope of "it isn't that hard, why don't other idiot devs just do <X>? It must be because they're incompetent." I'm not convinced you've drunk your own Kool-aid in production on a non-trivial project. Because then the trade-offs would be obvious to you and you wouldn't think one is better.
Also, some developers are developers because they wanted to GTFO of some situation and don't give two shits about personal development, best practices, efficiency, long term maintenance, or any else. They're just showing up for a paycheck.
Ideally you want to avoid those developers but realistically you don't always have a choice because not everyone who is passionate about software can work for Goopplebooksoft.
I think it helps a lot more to show that you understand styling principles (reusability, selector precedence) than it does to be able to make pixel-perfect implementations based only on knowledge off the top of your head. [0]
That being said, in order to have that understanding, you probably need to have some experience with CSS or similar.
Basically, hands-on CSS experience is the means not the ends.
[0]: Perhaps all of this is what you meant by having a "firm grasp of CSS".
We currently have ~3 dedicated front end developers who have limited skills beyond HTML, CSS, and Javascript who maintain our large forward facing public presence.
The remainder of our developer pool are full stack developers who maintain a myriad of internal systems and apps used to run the business. A few of these apps are publicly accessible but they're niche and don't require strict adherence to brand or accessibility standards. The remainder are simply internal applications.
A firm grasp of CSS would seem to be essential to the front end devs, though I might be inclined to say it's not given some of the code I've seen. I am however willing to give them the benefit of doubt because I know they're a newer team that inherited an unfathomably large site running on an ancient CMS (Stellent) and the new products they're working on are integrated with some pretty heinous 3rd party platforms.
For the remainder of our Devs usability and appearance take a back seat to functionality. So CSS chops are more of a nice to have.
Our organization adopted Bootstrap because it's a consistent and familiar framework and it takes less time for the inexperienced developers (most in my experience) to come up to speed on an app.
When you have 20 developers rotating responsibilities between 40+ apps with regular turn over and contractors cycling out, have consistent project setups and standard frameworks across the organization is essential.