It's that specific difference that we're trying to capture in a safe/sound distinction. Even if casual usage of the terms is casual, it definitely helps if written material consistently uses two different terms for the different meanings.
Even pure synonyms are noticed when used for disjoint (but related) concepts consistently. If we save even one moment of thinking between "is this "unsafe as in human-checked" or "unsafe as in causes UB", then the term split is worth it. It doesn't even matter if it's a conscious acknowledgement in the reader if we can bias them towards assuming the correct case from the start.
I understand the position of "terminology doesn't matter that much, context will figure it out," but I don't agree with it. (Maybe it's my formal background coming through.) Terminology exists to help the reader understand faster, and we should especially try to make understanding easier around unsafe (as in human-checked) code.
That's why "jargon" isn't great: you either know the meaning or you don't, and if you don't, it's worse than a more ambiguous but more obvious term.
Oh, and one more thing:
That's not correct. Code in an
unsafe block is just as checked as code not in an
unsafe block. It "just" gives you the superpowers of 1) dereferencing raw pointers, 2) using
union fields, and 3) calling other
unsafe APIs. This gives you the power to break rules upheld mechanically in not-
unsafe code, but nothing changes about the safe subset of the language.