Hi,
You seem to be asking two main questions here. The first question seems to be whether to use frameworks/grids or to build them yourself and the second question seems to be about building re-usable css.
The answer to the first question is not always straight forward as it depends on the actual job in hand. If you are creating a “one-man-band” website where you are the sole coder then in most cases you don’t need a grid or framework to help you as setting up a a few columns in basic CSS takes minutes and minimal code. Most of us already have our default templates set up and ready to go with all the code that we need and like for the task in hand anyway.
If on the other hand you are part of a team and building a large website with multiple components then frameworks/grids (like bootstrap) can standardise the process and make the job much easier and quicker but at the cost of some code bloat. Bootstrap for example has all the components you will likely ever need built into it and it’s a few seconds work to throw in a nav that scales responsively and magically turns into a dropdown for mobile. Or create popups, dropdown menus, collapsible menus and many other things with a few keystrokes or a simple copy and paste. This allows you to build large, solid and reliable sites quite easily and quickly as long as you stick to the basic defaults.
The other benefit of a grid is that all the other members in the team must use the same format and so standardises the process so that you don’t get so much spaghetti code being passed back and forwards - although you can never guarantee that…
On the other hand if the project in hand is very stylised and not “grid friendly” then it can take longer to build as you have to bend the framework to fit. The other downside of a framework is that there is a steep learning curve and you have to get used to someone else’s way of coding.
In answer to your second question the secret of using reusable code is to abstract and standardise the elements that you use so that you don’t reinvent the wheel on every page. Don’t be too specific with your rules e.g.
nav #nav li strong{background:red}
when something like
.highlight{background:red}
Is much more usable even though it means adding a class to the strong element.
Don’t be afraid to add classes!
The number of times I’ve used things like #main p{margin:0 2em} and then need to make special cases for other p elements and need to over-qualify it again #main p.special{margin:0}. It would have been much better just to have added a class to the p element to start with. The other problem with specificity like the former example is that it hits all p elements in that section and who knows in the future what else may be added into that section. You may have a re-usable snippet that fits nicely into that section but it then gets hit by the rules cascading from above.
There is a time and place for being specific but usually within smaller contexts where you are happy that things won’t change.
When you build an element that is being used across a site then create the basic standard structure first and then you can if required modify that structure where needed with a modifier class. If you do this carefully you will not need to cancel styles out but just add to them instead. (It also helps to tell your designers not to change the element on every page just because they think it looks neat).
As far as media queries go then I’ve completely changed my approach and I no longer contain all the rules in a single media query for each layout. I use multiple media queries throughout the stylesheet and I include them right after the element (or a suitable group of elements). If I build a container then I will give that container the rules it needs for all viewport widths then and there and not hide it away miles away from the section it refers to.
e.g.
.test{
normal styles here......
}
/* media query for that rule goes here here */
@media screen and (max-width:980px) {
.test{tyles here....}
}
.more styles{
more page styles here..
}
It does mean you have more code but you end up with a more logical approach and one that is easy to construct as you go and easier to modify later. If you use the old method then it becomes almost a separate job where you build the main layout first and then you go and make the alternate versions. The problem with this is that it may be too late to make something work if you wait until the end. Therefore build and test each element as you go across the viewport width and adjust html and css until it works and then move on to the next element.
That’s just a few thoughts off the top of my head and probably not as well presented as it should have been 
