Both of those things are true. Many CVEs are unimportant, but serious security vulnerabilities do exist, and are very hard to avoid entirely when writing C.
The CVE severity scores kind of make sense in absolute (Daniel's post clearly shows that this isn't always the case) but many companies have an inelastic, inflexible, unthinking approach to them which really frustrates our effort to prioritize actually relevant stuff.
A CVSS 10 on a log4j library sitting unused in a folder, shipped with an app that isn't even running, should not have prio over an unauthenticated RCE on an internet-facing service without even a WAF in front of it. But hey, that's only a 9.2. Try having this discussion with an auditor. (I don't want to lump all auditors together - I have ~12 years of collaboration with them and met some excellent ones - typically the ones we lose after a short time because they're wasted on us. And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit).
> And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit
The job of an auditer isn't to make you secure, its to make sure you aren't lying about implementing your security policies. If your policies are stupid, all they are going to do is ensure you follow your stupid policies.
Even memory safe languages do not technically eliminate all memory issues but they significantly reduce the amount of code you need to audit for memory issues.
You have no magical way of removing all memory security issues but you can definitely reduce the chance of one occurring by picking one of those memory safe languages.
The less time you have to spend on checking every piece of code memory allocations the more time you can spend on checking business logic for logical errors.
That blog post is talking about something else though. He's saying that the CVE system does not do a good job and allows for people who drums up severity for drama. That is just a generic issue he has with the procedure. You can have severity written in C to JavaScript to even Rust, or just simple configuration mistakes. That's not what he's complaining about.
In fact, him saying that this vulnerability is high is part of the point. If every single bug or vulnerability is a "high" severity bug, then nothing really is. It's only when you use this rating when it makes sense to that it would have the proper impact.