All the issues basically boil down to "nobody wants to do the busywork of CVE filtering, triage, rejections, changes".
As a developer, kernel or otherwise, you get pestered by CVE hunters who create tons of CVE slop, wanting a CVE on their resume for any old crash, null pointer deref, out of bounds read or imaginary problem some automated scanner found. If you don't have your own CNA, the CVE will get assigned without any meaningful checking. Then, as a developer, you are fucked: Usually getting an invalid CVE withdrawn is an arduous process, taking up valuable time. Getting stuff like vulnerability assessments changed is even more annoying, basically you can't, because somebody looked into their magic 8ball and decided that some random crash must certainly be indicative of some preauth RCE. Users will then make things worse by pestering you about all those bogus CVEs.
So then you will first try to do the good and responsible thing: Try to establish your own criteria as to what a CVE is. You define your desired security properties, e.g. by saying "availability isn't a goal, so DoS is out of scope", "physical attacker access is not assumed". Then you have criteria by which to classify bugs as security-relevant or not. Then you do the classification work. But all that only helps if you are your own CNA, otherwise you will still get CVE slop you cannot get rid of.
Now imagine you are an operating system developer, things get even worse here: Since commonly an operating system is multi-purpose, you can't easily define an operating environment and desired security properties. E.g. many kiosk systems will have physical attackers present, plugging in malicious hardware. Linux will run on those. E.g. many systems will have availability requirements, so DoS can no longer be out of scope. Linux will run on those. Hardware configurations can be broken, weird, stupid and old. Linux will run on those. So now there are two choices: Either you severely restrict the "supported" configurations of your operating system, making it no longer multi-purpose. This is the choice of many commercial vendors, with ridiculous restrictions like "we are EAL4+ secure, but only if you unplug the network" or "yeah, but only opensshd may run as a network service, nothing else". Or you accept that there are things people will do with Linux that you couldn't even conceive of when writing your part of the code and introducing or triaging the bug. The Linux devs went with the latter, accept that all things that are possible will be done at some point. But this means that any kind of bug will almost always have security implications in some configuration you haven't even thought of.
That weird USB device bug that reads some register wrong? Well, that might be physically exploitable. That harmless-looking logspam bug? Will fill up the disk and slow down other logging, so denial of service. That privilege escalation from root to kernel? No, this isn't "essentially the same privilege level so not an attack" if you are using SElinux and signed modules like RedHat derivatives do. Since enforcing privileges and security barriers is the most essential job of an operating system, bugs without a possible security impact are rare.
Now seen from the perspective of some corporate security officer, blue team or dev ops sysadmin guy, that's of course inconvenient: There is always only a small number of configurations they care about. Building webserver has different requirements and necessary security properties than building a car. Or a heart-lung-machine. Or a rocket. For their own specific environment, they would actually have to read all the CVEs with those requirements in mind, and evaluate each and every CVE for the specific impact on their environment. Now in those circles, there is the illusion that this should be done by the software vendors, because otherwise it would be a whole lot of work. But guess what? Vendors either restrict their scope so severely that their assessment is useless except for very few users. Or vendors are powerless because they cannot know your environment, and there are too many to assess them all.
So IMHO: All the whining about the kernel people doing CVE wrong is actually the admission that the whiners are doing CVE wrong. They don't want to do the legwork of proper triage. But actually, they are the only ones who realistically can triage, because nobody else knows their environment.
The CVE system would be greatly improved by a "PoC or GTFO" policy. CVSS would still be trash, but it'd simplify triage to two steps: "is there a proof-of-concept?" and "does it actually work?". Some real vulns would get missed, but the signal:noise ratio of the current system causes real vulns to get missed today so I suspect it'd be a net improvement to security.
But you cannot PoC most hardware and driver related bugs without lots of time and money. Race conditions are very hard to PoC, especially if you need the PoC to actually work on more than one machine.
So while a PoC exploit does mean that a bug is worthy of a CVE, the opposite isn't true. One would overlook tons of security problems just because the discoverer of them wasn't able to get a PoC working. But it could be worth it, to maybe also keep the slop out.
The alternative is to treat all bugs as security bugs, which is valid since they by definition prevent the expected functionality of the program and are thus at least a DoS. This is essentially what Linux does. People don't like this because they often don't care about DoS bugs and it makes the CVE system pretty useless if they only want to see other sorts of security issues.
Please, tell me what issues you have with how the kernel does CVEs.