Except that it's not. At least on glibc, strlen() is declared "pure" to the compiler and (unless otherwise defeated by pointer aliasing) repeated calls will be optimized away.
That's not to say that this is the best way to write the code, but the concern seems poorly informed.
In practice calling any other non-pure function, which the compiler can't see in to, will defeat this optimisation, whether there's aliasing within your function or not.
Maybe you're saying it's a "code smell" kind of thing and that being sloppy here indicates more subtle problems elsewhere? Which then hits the argument about whether this is really "sloppy" or just intentionally simple.
Shrug. My point was just that this needs better evidence. There is no demonstrated bug in the linked code, and the assertion that it is "gross" (OP) or "insecure" (you) seems poorly justified.
[1] at least according to the post. The fact that gnutls added a binary interface later seems to support that reading.
If this was C++, and the function took a std::string, would you say it was horribly broken because you serialized a 4 byte IP address into a 4 byte std::string buffer and the function didn't handle it correctly?