I agree: this seems intended to address issues that arise when the user does not read documentation for the code they use. If the author did not document that the function locks already, they are unlikely to use this feature to do so.
There are many preconditions and requirements that cannot feasibly be accounted for by the compiler, and no language will ever be able to supplant the need to read documentation in some fashion. Those likely to benefit from this are just as likely to run straight into another issue, such as misunderstanding the actual effect of a method.
There is already an established convention for identifying functions capable of undefined behavior in the event of improper use. We do not need a compiler-level form of that.
If this is a sufficiently common problem, I have a counterproposal: add a boolean field to Swift’s markup syntax specifically for asserting that a function locks. That could allow automated tools, such as IDEs, to provide some guidance at their discretion.
By the way, isn’t Sendable intended to assert that a block of code is safe for use with concurrency?