During the period in question, we know of at least one vulnerability (Heartbleed) that could have been used to extract private keys from software TLS implementations. There are still other, unreported vulnerabilities that could be used today.
His analysis that there are unreported vulnerabilities in TLS implementations sounds definitive enough to think he knows some of these vulnerabilities.
Not at all. Given the history of TLS implementations, I would call "There are exploitable vulnerabilities" the null hypothesis, and require extraordinary proof that a particular TLS implementation doesn't have vulnerabilities.
Perhaps, but this is an academic security researcher we are talking about. To generalise massively, academics are very deliberate and conservative in their language.
If he wasn't aware of at least one unreported exploitable vulnerability then I would expect him to say "There are almost certainly still other, unreported vulnerabilities".
As an academic, he has probably verified that the underlying algorithms are as sound as claimed. Problems like Heartbleed come from implementation errors. Implementations are very prone to error, so there are almost certainly still other, unreported vulnerabilities.
From the article, it would seem that side-stepping this, and going directly for the routers, or even the employees, is more efficient in actually circumventing encryption than hunting for vulnerabilities in encryption implementations.
His analysis that there are unreported vulnerabilities in TLS implementations sounds definitive enough to think he knows some of these vulnerabilities.