The argument with "" as suffix sounds quite absurd.
Why do you believe POSIX would never approve a str_t type? Nobody likes raw char arrays, perhaps a future revision of POSIX may decide to make the lives of C programmers easier and implement their own sane string type.
Now extending the suffix to "_t" doesn't make it much less absurd. Not qualitatively, just a bit quantitatively less absurd.
Why I suspect POSIX isn't about to add a str_t is that str_t is likely to occur in countless numbers of unknown existing code bases.
And that might be a good reason for avoiding it in a library API, not the _t namespace being reserved.
We can have this variant of the argument: most identifiers end in a lower-case letter, so they land into any one of 26 namespaces: the *a namespace, the *b namespace, ... future POSIX identifiers have to be in one of these 26, except those that end in digits or underscores. POSIX does not say "future versions of this standard shall not claim new function or other identifiers ending in e". That doesn't mean you stay away from identifiers ending in "e", right?
I wouldn't avoid str_t in the internals of a program though. In the worst case, a clash happens somewhere and we do some renaming; life goes on.
POSIX's reservation doesn't really mean much; all they are saying is "we have some type names ending in _t, and will likely have more, so watch out". Yes, POSIX will likely have such names, and so will every C programmer and his dog. Whoppee dee. POSIX will likely have new names ending in 'e' also, and so on.
I for one like "raw char arrays", and really don't care about missing string functionality in C. I basically use sizeof, snprintf, memcpy and am just fine. I've toyed with defining struct String{ptr,size} sometimes but largely it just gets in the way.
If you think it's necessary, it's very easy to make an argument that you'd have to have a generic type for slices of any type. (Actually, more so than strings, since C is just not a language for domains with a focus on strings).
Now, whether you think a language must have a generic slice type or not, C is simply not the language where you can fit that in.
Why do you believe POSIX would never approve a str_t type? Nobody likes raw char arrays, perhaps a future revision of POSIX may decide to make the lives of C programmers easier and implement their own sane string type.