I absolutely appreciate respectful disagreement!
The point I often try to make is just how easy it is to get the right result, for the wrong reasons. (especially in loose languages like JavaScript). It goes from making more scientific proofs to, "I saw what I wanted to see on the screen - I can't exactly say why, but I think it's because my code is sound".
It's the equivalent to, "this new flea killer kills twice as many fleas". "What did you change?" "Four different things", "which one ended up being the thing that actually made it work?", "dunno, but now we're seeing twice as many fleas dead!".
I think underlying Kent’s statement is an observation that is undeniably true. The closer a test is to the actual way the software will be used, the better it is in a number of ways, _all else being equal_. All else is never fully equal, which is why everything is about tradeoffs.
But when a test aligns with how the software will be used, there are a whole bunch of synergies and benefits. Simplicity increases, clarity increases, you start getting multiple payoffs for each bit of effort you invest.
I’m sure people cargo cult it and lose track of the tradeoffs, like anything else, but there’s a solid point under there. And I agree with him, it is valuable enough to be called a “best practice.”