The complaint isn't about the semantics, but about it furthering an image of the Rust community that's working against it when it comes to actually fixing this. Being "right" is less effective if you are being insufferable about it.

Actually it is the security community, Rust isn't alone on this endeavour.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

C.A. Hoare stated on his Turing award speech done in 1981.

I can relate to other remarks or papers from memory safe systems programming all the way back to 1961, when Burroughs B5500 was released.

Yet many keep not paying attention, like Microsoft bosting 70% memory corruption issues on one side, while selling Azure Sphere security pitch having only C as available language, or bosting the use of C++ on WinUI, among many other examples.

70% of CVEs (bugs detected) being memory related does not mean that 70% of all software bugs are memory errors (bugs that exist). See survivors bias. Memory errors can be detected with the assistance of programs, so they are much easier to find than other bugs like logic errors, which require knowing what a program ought to do. I think the latter is much more insidious.

Sure, but not particularly relevant to how the Rust community is perceived. Well, maybe, if people think you are more insufferable about any topic than the infosec community, that is actually kind of impressive.