This argument doesn't hold water. They're absolutely no worse than strcat/cpy and strncat/cpy, which glibc implements. I totally disagree with your premise that truncation is an incorrect use.
In reality, the alternative to strlcpy/cat isn't "force programmers to write correct code," it's "programmers will just use the crappier available functions with even worse behavior on overrun."
Perhaps you have some better reason why Posix has rejected it, again and again? Some sort of conspiracy is conceivable, but in service of what?
I have seen much, much better designs, that take into account that these functions are rarely called in isolation. In those, calls cooperate with previous and subsequent calls to share the burdens of maintaining correctness and safety.
POSIX never rejected strlcpy/strlcat, because they were never submitted for inclusion. Also, POSIX doesn't control the str* namespace, ISO C does. Not that it matters, as it wasn't submitted there either.
But that's beside the point. Every major OS's libc has an implementation of strlcpy/strlcat, and OpenBSD's can be readily lifted into a project's source tree as it is portable, a simple code search will reveal the breadth of adoption. The /only/ exception is glibc now. And glibc is not a standards committee, for years the primary objections came from one person.
In reality, the alternative to strlcpy/cat isn't "force programmers to write correct code," it's "programmers will just use the crappier available functions with even worse behavior on overrun."