I could see some value to a kind of measurement like that, but I agree that that particular method seems heavy handed.
This is partly what SBOMs are meant to solve for.
I’m also not sure calling Linux “aging infrastructure” that is obscured by activity in the Kernel is intellectually honest. Perhaps it’s better framed as a naive take. If the point is about shopping the rest of the OS (“all the dependencies” if you will) being a supply chain issue, I think the point would be better.
A vulnerability with CVSS 2.5 wouldn't have a quarter of impact of a CVSS 10 vulnerability, its impact would be insignificant.
A CVSS 10 on several internal services with all user input being filtered may be substantially less risky than a public facing component using a library with a CVSS 2.5 depending on your application and vulnerability.
The only correct way is to assess risk is analyze how you utilize each component and determine if your application would run into the issue to begin with. This work cannot be hand-waved away with a simple number despite this practice being the hot fad in cybersecurity.