Efficiency is not the goal. Security and safety are. strlen() in kernel code on an (intentionally malicious) unterminated input has the potential to go off reading some other process's data, which opens up possible attack vectors, or the potential to cause unexpected page faults. strnlen() with one greater than the true buffer size, with the one extra memory read that it implies, has the same potential.
No, strnlen with any given length does not have the potential of reading anything that it should not read, like it is true for strlen.
The length argument of strnlen is under the control of the kernel writer, not under the control of whoever provides the source string.
The new strscpy function can also read anything, if the kernel writer allocates a destination buffer long enough, there is no difference between strscpy and strnlen, from the security POV. What they read is determined by the length of the destination buffer.
Because the destination buffer must have an extra byte for the null terminating byte, strnlen must be called with the size of the destination buffer as argument, but if it returns that size, that signals an error, and then a number of bytes that is one less than the return value must be copied from the source (and a null byte must always be written after whatever is copied by memcpy).
The kernel function strscpy is exactly equivalent with using correctly strnlen and memcpy. While strscpy encapsulates that behavior, so it is more convenient, anyone who wants to use strscpy in a user C program must define a strscpy macro or function, using strnlen and memcpy, which are standard functions.
The length given to strnlen() is, as you yourself said, greater than the size of the actual buffer in order to detect an oversize source. So strnlen() has the potential to access the character beyond the end of the array, checking it for NUL, incurring page faults and whatnot.
