We don't prioritize code over comments because it can be automatically tested, we prioritize code over comments/spec because the code is what gets executed.
And I can say "this can't be done under these time constraints" at my job. If you can't, then you're not being taken seriously because of some other reason, not because you're a programmer.
My previous comment ("If that's the way you work, then your employer has made a mistake") was ambiguous, and actually illustrates a point regarding comments (and documentation in general). Like that comment, the short verb phrases that make up source code cannot always express the intent of the programmer (extreme 'self-documenting code' advocates think otherwise, but their experience with simple programs and algorithms doesn't generalize.) In such cases, comments are a good way to explain a design issue that is not obvious.
Who cares about these things, which don't change the code? Anyone who needs to understand the code, which includes anyone working on it, including its original author - writing a brief explanation of a tricky point can help you spot mistakes before you compile or test, or even before you write the code. The goal is to produce correct code, not just code, and the one thing that is faster than continuous testing is avoiding mistakes in the first place.
FWIW, I think the idea that comments need to be complete sentences is silly. Sentences can be as wrong, ambiguous, misleading or uninformative as simple phrases.
And I can say "this can't be done under these time constraints" at my job. If you can't, then you're not being taken seriously because of some other reason, not because you're a programmer.