Backdoored tools are a pretty different threat from unknown cryptanalytic advances and should be addressed in different ways. A lot of research right now aims to address different backdooring methods (I gave a related talk at CCC a couple of years ago); a first step is to make sure that published source code corresponds to binaries and that all users receive the same software updates. Neither of these is guaranteed today, but we're making progress toward both.
A trickier problem is bugdoors, where someone intentionally introduces an exploitable vulnerability into a code base. The underhanded C contest points at some of these risks
https://en.wikipedia.org/wiki/Underhanded_C_Contest
and then we've had
https://underhandedcrypto.com/
and
https://underhanded.rs/ (which was just mentioned here on HN)
It seems likely that this approach has already been used against some important software somewhere, regardless of the specific methods and incentives used to get it into the code.
Maybe the experience gained from these contests will point at ways of avoiding bugdoors in the future, whether formal methods, static analyzers, changes to language specifications, coding standards, improved auditor skill, or something else. (I'm personally a bit hopeful about formal methods; they've seen an encouraging new level of success in the academic world over the last few years.)
There are definitely principal-agent risks in having everyone use Signal or GPG. But you're not going to invent something as secure as AES by yourself, nor something as secure as Signal or GPG. The crypto world has made massive advances in the last couple of decades by respecting Kerckhoffs's principle. There are worthwhile arguments like
https://news.ycombinator.com/item?id=11854576
that you can get a security benefit against some threats by adding some non-globally-shared obscurity layers. That doesn't mean you can go off on your own and do as well as publicly-scrutinized stuff does.
I think I should get the authors of "Imperfect Forward Secrecy" to opine on this. They may have identified one of the decade's biggest security problems from cryptographic monoculture, but still I doubt they would agree that we can make much progress with home-grown communications security solutions. (But as discussed elsewhere in this thread, it would be helpful to have good guidance for secure composition of cryptographic primitives, so if you're not sure of one layer and want to add another, you can at least do so in a way that doesn't make things worse.)