I don't like the philosophy behind commenting code. It seems to imply that the code itself isn't understandable. And that is the fundamental problem.
The author can't write understandable code.
The reader isn't qualified enough to understand the code, and shouldn't be let anywhere near it .. comments or not.
The language isn't expressive enough.
IMO, this is in order of commonality. All these are some kind of failure. Comments thus are a crutch for some kind of deeper failure in the code, organization doing the commenting, or programming language.
If comments were docile, I'd let it pass. But from the perspective of the machine, they aren't falsifiable. So:
They can outright lie (maliciously even.. only code can be trusted) or get stale or just wrong over time.
They can't be proven correct (see: unit tests for an informal but pretty effective way of testing the functionality of code, AFAIK no equivalent exists for comments).
I feel that adding the ability to comment code is up there with the "null" type in the fail department of programming languages, ie. one of the worst ideas to ever grace the programming profession.
Unfortunately, because comments are so easy to add to programming languages, they will continue on forever I'm sure.
I agree with the principle, but I think you are taking things too far.
Just to make an example, the readability of any piece of code is strongly correlated to how meaningful are the identifiers the programmer chose. Yet, identifers are just as unverifiable and potentially misleading as comments.
If anything, yours are excellent arguments for the introduction of optional type annotations as they make it easier for programmers to express the intent of the code, when needed, and provide some implicit verifiability.