skip() would imply that we know beforehand whether the test is going to fail or succeds.
If we know that a test is going to fail, we mark it as todo or broken. If it succeeds, we have no reason to skip it at all.
We use skip() _because_ checking the outcome of the test would not be meaningful, whether it is success, failure, or outright crashing of the test program. An example of this would be missing API, lack of implementation, or unavailable test target (e.g. Internet connectivity).
The same applies to flaky tests in that their results are unreliable and thus not effectively meaningful for the purpose of conformance verification. What makes the flaky tests different from skipped ones is that the tests themselves are required not to crash (or lead to undefined state) since they actually run, and the developer is sometimes interested in whether they actually succeed or not.
Anyway, my idea is that we should prevent the flaky mark from going stale when the test gets fixed _but_ the corresponding patch fails to remove the (now outdated) mark, especially if the author is unaware that the patch actually fix the flakiness. We can't do much for skipped tests; however, flaky test has increasing probability of being useful (i.e. not flaky) as their success/failure streak increases.