A major problem with your approach is that it assumes analyzing a binary for correctness or security is equivalent to analyzing well-documented, high-level source. It's not. It takes much more work to discover vulnerabilities in assembly or even correctness failures. That's because it lacks the context for how the software is supposed to operate.
I can read a commented Python or BASIC program with almost no effort unless it's very sloppy. I can tell you a MISRA C or SPARK program with associated static checks is immune to entire classes of errors without analyzing the source myself. I can tell you what information flows can or can't happen in a language like SIF implementing information-flow security. I can do all of this while expending almost no effort. So, I'm much more likely to do it than if I had to decompile and reverse-engineer a binary from scratch with analyses using the tiny information in a binary.
So, every time you say that, what you're really saying is: "Anyone could do this if they spent enormous time and energy. Sort of like they could hand-compile their C code each iteration. They probably won't but I'm countering your wanting for source because in theory they could do all this with assembly with enough effort."
It's definitely not true for correctness as assembly lacks what you need to know it's correct. It's probably not true for security as correctness is a prerequisite for it. In any case, economics is important where the effort required to achieve a thing determines whether someone will likely spend that effort. In case of binary analysis, it's apparently a lot less than source analysis.