CVSS is a poor metric because (by its own definition / admission) its got a very narrow intent: it doesn't really deal with exploitability in any meaningful way (like e.g. the shell access required here). There is a lot of ongoing discourse on its limitations, but its all in relatively early stages & imo its better to have something than nothing (especially when the maintainers of that "something" are aware of its limitations & actively working on better processes).
If you have 10 security bugs, 3 are genuinely high severity and 9 get assigned high severity by NVD, then at least you've managed to deprioritise one of them. It's something (unironiccally).
CVSS is really just used to stack-rank issues and decide how to handle them. Orgs get a list of CVEs, they sort them by score to decide which ones to handle first. From there someone removed from the actual process comes up with deadlines such as "All critical issues, defined as 9.0 or above, must be handled in 30 days." If they are reasonable there is additional language around "or best efforts must be made to resolve or mitigate the issue." If not, gghfdd.
If you have 10 security bugs, 3 are genuinely high severity and 9 get assigned high severity by NVD, then at least you've managed to deprioritise one of them. It's something (unironiccally).
This is a pretty decent overview https://www.first.org/epss/model