But while "no patch available" is a problem, I think it's the wrong problem to think about. One obvious concern about that line of thinking is that an exposure is an exposure regardless of whether there's a patch available.
The bigger problem, not just with container scanners but with all sorts of scanners (Node dependency scanners are another good example) is that there's a huge incentive to "enumerate" vulnerabilities with CVEs, and most of these vulnerabilities are meaningless.
I spent a couple years at my previous gig triaging security scanner results. Like pretty much everyone who does this professionally, I got so I could do this pretty quickly, and without much though about my actual environment; whole classes of vulnerabilities are pretty much garbage, and most people would be better off if their scanner required a special flag to alert on them.
What you really need to know is, given a vulnerability, is it likely to constitute an exposure in my environment? Clearly, a scanner vendor can't do this analysis perfectly. But they can do more than the zero they do now.
I started my computer security career at a firm called Secure Networks. We sold a security scanner called Ballista. We competed with a much-better-known firm called ISS, who sold the eponymous ISS scanner. The big debate between us and in the market was how to "count" vulnerabilities; ISS, for instance, had a huge collection of Windows registry best-practices rules, and claimed every one of them as (in effect) a vulnerability, while we tried to claim only what our scanner could actually exploit.
We lost that debate, obviously, and the CVE system followed shortly thereafter.
I think the general thing to keep in mind is that, for the most part, modern security scanner teams are pretty small. They're driven off vendorsec and CVE feeds because that's automatable. Like ISS vs SNI, they compete with each other, and their figure of merit is often "how many", not "how important" --- a metric they're not staffed to generate anyways. I wouldn't put much stock in their results.