A huge segment of the community pushing static typing use the “You don’t need as many tests!” argument for it. So it’s kind of normal that the reverse argument will come up in an article like this.
Of course, you want both. They don’t cover the same stuff. Though if you do unit testing right, the surface area that static type checking covers become drastically lower. If I have a test that checks expect(something).toEqual(123); and I properly cover my code paths, I now have a guarantee (not in the math proof sense, but still effectively a guarantee) that something is a number.
So adding static type checking to it won’t actually catch any bugs there. It will make tooling better. It will make it easier to write the test. It may catch a bug if I wrote my test wrong. But for that particular bug surface, it’s an overlap.
Of course, I’ve seen people write tests like expect(foo).to.be.a(‘string’) or whatever. Forgetting the fact that test should never have been written, those obviously go away from the mind of the author once you introduce static type checking.