What I said is that runtime checking is better if you have a test suite that's good enough.
A way of discussing it that doesn't place them in competition with each other would instead talk about their relative characteristics, including factors that might make different options more or less effective (or even inapplicable) in certain circumstances.
For example, there are certain classes of defect that cannot be detected at runtime. But what does and does not fall into this category depends on what programming language you're using. There are other classes of defect that cannot be detected statically, and the specifics of this list also depends on what language you're using.
And then there's also a bunch of overlap, but the relative merits of one or another way of solving things cannot be boiled down to a simple "better/worse" hierarchy. The optimal strategy is often domain-specific and finding it may require weighing many tradeoffs.
Absolutely not. It says that they have tradeoffs, and one will be better in certain situations, while the other will be better in others.
If you think that means competition, you're overreading it.
You want a test suite, but it's never better or good enough.
Abstract Interpretation in a Nutshell https://www.di.ens.fr/~cousot/AI/IntroAbsInt.html
That is a wild claim.
But how many false positives does it have?
Too bad it's not FOSS; I would pay for that is the false positive rate was not too high.
We are talking code without dynamic memory allocation, recursive function calls, no system and library calls, of course. Like some embedded aerospace, automation, healthcare and military applications. You can use it to verify some libraries if you can't do full coverage. Application domain abstractions are also available.
NASA has open source tool called IKOS based on same abstract interpretation concept, but I don't know it's features.