How about you fix the flaky tests? Am I insane for thinking that? The whole concept of "just reboot it" or "re run it again" and "fixing" the problem is at least one reason the modern world sits on a mountain of complete garbage software.
Once the test is skipped, a domain expert can come back and take a look and figure out why it was flaky, and fix it.
If it's urgently broken (e.g. there is real impact), we treat it like an incident and gather people with the right context to fix it quickly.
As long as everyone agrees to these norms, it's not a huge burden to keep this up with thousands of tests. People generally write their tests to be more resilient when they know they're on the hook for them not being flaky, and nobody stays blocked for long when they are permitted to skip a flaky test.
In another case observed, devs just got used to rerunning the entire suite (the flakiness here was about 10-20%)
Another way to think about it is, whether Flaky tests are worth keeping? At some point if the tests fail often, do these really add value. And we think - it does. If you are able to identify flakiness from real failure and reduce noise, you can still avoid real failures.
There may be a point where the cost of ownership for a specific test exceeds its utility, but the way to resolve that is usually to reevaluate your code and supporting tests. Suppressing flaky tests seems a very unwise choice.
Perhaps under extreme circumstances and with unhealthy code bases there may be a case for this, but I struggle to imagine it.
Fixing flaky tests can very commonly take longer than writing new tests.
Yes, I'm mostly agreeing with you that the tests should be fixed, but I have seen ones that were perfectly fine (given the constraints) and what should have been fixed was the CI.