To be more realistic, Flash was a much smaller attack surface than downloading and running random executables. I'm guessing that a fairly small number of kids were actually subject to Flash exploits while playing games on Kongregate. Compare that to downloading a screensaver...
Things that native apps can do trivially but that require explicit permission for accessed in Flash (or the web in general): filesystem read/write, listen in on microphones, spy with webcams, etc etc.
If you have a flash zero day (and they totally exist!), you can do those things, but that significantly raises the difficulty, which reduces the number of attacks you'll actually see in the wild. Most attackers aren't the NSA or Mossad, and resources that they have to spend on getting and exploiting zero days are resources they can't spend on other parts of the exploit chain.
The Flash API surface does not include direct host access the way the native application API surface does. That means that while identifying native apps doing "bad things" requires solving the halting problem (and moral philosophy), any ability of Flash applets to do "bad things" is an unambiguous bug. Sure, without a sandbox those bugs are easy to exploit when they exist, but they can nonetheless be fixed.
I wouldn't trust Flash from 2005 against NSO Group from 2020, but I'd certainly trust it against the author of the Melissa virus.
Another way of putting this is that there are two senses of "sandboxed" - one is having a limited API surface and one is using software fault isolation techniques on the interpreter/runtime itself. Flash (and JS) always had the former, even though the latter is fairly recent.
