I don't know of any framework that you can implement yourself that is on the one hand so broad, that it touches every possible security issue that might come up in a penetration test and is on the other hand so specific, that it provides an exact scoring system.
I understand risk assessment depends on many factors and environmental
differences, but is there still a rough guide that can be followed?
There is at least one more important factor to look at, and that is the organisations "appetite for risk". A specific risk is a "High Risk" for one organisation, and a "Medium Risk" for another. If your company tends to make high risk business decisions on a regular basis, they might accept risks that others just wont.
Your given example was a visible CSS file. It seems that you would say: "Hey, as long as it is not exploitable now, what's the harm? That's not a high risk!". The reasoning behind their justification is (maybe): "It may be not exploitable now, but we don't want source code to be visible, so attackers don't get ideas on HOW to exploit it in the future." (Which is a reasoning I support to be honest.)
IMHO, there are two things you can do.
Coming from a methodical viewpoint, use the Common Vulnerability Scoring System (CVSS) and compare their findings to vulnerabilities in vulnerability databases that are publicy available, like this one. (Search Sec.SE for a lot of questions on this topic.) This will give you an idea on how serious a vulnerability is and also will lead you to a better evaluation of the findings of the penetration tests.
Coming from a business viewpoint, get in touch with the penetration testers and ask questions. Challenge their findings and find out what the reasoning behind their assessment is. If you get the feeling, that every identified risk ends up being a "High Risk", suggest another penetration tester to your client.