By that logic, people would also be better off using C++. In many cases it'd be easier to port a C project to C++ than to adopt glib in all its monstrous glory.
Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string? Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments. Getting strlcpy into glibc would be just one less extra burden to carry when trying to write sane, simple, secure code.
And also, why do I need a dynamic string object? Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters? Are DNS labels magically going to become longer than 63 characters, or domains longer than 255 characters? Do my enum-to-human-readable-string mappings need an indefinite buffer?
Most people who code in C aren't doing unbounded string operations. Not every C application or library is an editor or a text processor. In fact, very few are. Don't confuse "C-strings" with "strings". People don't use strcpy or strlcpy to manipulate "strings" (the abstract computer science concept); they use them to manipulate C-strings, a very narrow and well-defined data type which in practice is almost always bounded by a rather small limit.