Think of it like different construction methods - you can build something, let's say the Pyramids, or you can take something already built and beautiful, but is not what you need, and slowly curve Petra inside the walls. Both work.
In fact, if you are sticking .row and .column everywhere you are doing considerably more work than just to define a grid layout using display: grid once in your CSS, and then just use semantic HTML thereafter.
Flexbox has very good support and consistent behaviour in all major browsers and for most of the time we can use flexbox model. With some learning for using flexbox and grid I could appreciate their utility. (though I do not use CSS regularly)
The state of CSS is very much improved and these days we don't have to depend on hacks like the float and clear in CSS. But, minor problems like the inconsistent behaviour of display:grid in IE 11 - make the need for a CSS framework relevant.
The layout in grid can be responsive. But the layout in flexbox for IE 11 only will be mobile, if it's mobile it will work in any display.
So what happens when the framework does something unexpected? Or, as is more often the case, you run into a situation where you need to do something to satisfy the requirements of your project that the framework simply didn't think of? Again, you can dive into the internals of the framework to figure it out.
I'm arguing that in the long term you're better off learning CSS. Then you KNOW you can do what needs to be done. And with CSS you can still use a framework if you want but fall back to pure CSS if and when you need to.
Except nobody has the time nor role to organize and maintain your project's CSS like Spectre.css' developer could. And nobody wants to because CSS accumulates technical debt rapidly. Everyone opens up that file just long enough to do what they need and then they get out before the house of cards falls down. To avoid adding rules that break existing UI, they add a new class and a new rule just for that class to be safe.
And let's say you're a CSS master. Which doesn't help all that much beyond being able to maneuver in the mess that was created. The above paragraph happens in projects where everyone knows CSS just like a project can evolve into spaghetti code between capable developers over the terrain of changing requirements. And being a CSS master equips you to understand a CSS framework too, so I don't understand why you keep alluding that CSS knowledge makes frameworks obsolete. I'd rather read organized framework code than whatever the bespoke clusterfuck people end up when left to their own devices under the constraint of time and deadlines.
Frameworks help contain complexity. They aren't just a tool for beginners and non-professionals.
You're making the wrong assumption that messes in programming are only made by not knowing the language. I remember thinking the same thing at my first job out of uni, but I was quickly straightened out at my first job when I realized that being good at a language meant almost squat against the real reasons: real world applications fighting between churning requirements, business concerns, and scarce developer resources like time.