Without knowing the cause of the kernel panics, such reports are meaningless. In every case, the question must be asked: What does Apple say is the cause.
Tech Support calls must be made and crash reports must be forwared to engineers on your behalf. Reporting to Apple does not do this. Going to Support and asking for a call back does.
I've been working with Apple on these for a few months now. So far, every one we've found was caused by something old — removing it solved the problem. Sometimes, it takes Apple Engineering awhile to find the exact cause, however. This support is free even if no longer under AppleCare as long as the OS is currently supported — through October, that means High Sierra and newer. In November, 2020, OS 10.13.x will be dropped from the list.
The one that happened to me over Mojave with the March 2020 Security Update took six weeks to resolve. The culprits were an old Soundflower .kxt and another for NIGuitarRigII — both had been installed to ensure compatibility with OS 10.6/7. BTW, those same .kxt files were found on my Catalina machine but it never crashed (I still removed them, of course). Obviously, the only change upon removal was no more kernel panics and crashing. With my clients, I have a list of over 30 other causes including HP drivers from 2005 and Finale 2009 Help files...
Contrary to the many threads on the subject, the T2 chip/BridgeOS is not the cause. It's the symptom and the first thing seen in the crash report. Think of it as the canary in the coal mine.
It would be nice if the BridgeOS was more tolerant of old, obsolete and poorly written code — but it's not. Perhaps with Big Sur — beta has been promising.
Since my spouse has crap on her 2011 reaching back to the Stone Age (ok, her Performa 6200), I expect to be going through this all over again on hers. Apple will own any hardware issues for the next three years but they'll own OS issues for as long as they're still supported. I will hold them to it as I have been doing since the Mac Plus.