I didn't read it that way at all. Consider the audience: the questioner admits that they are new to C. Because of that, the author of the accepted answer wanted to make it crystal clear that code like this should never be written "especially if you're not a C compiler / standard library vendor". The answerer explicitly acknowledges that the code depends on implementation-defined behavior.
IMO, the answer is great. It starts with a strong warning to never write code like that in your own programs (which you shouldn't), and then explains how it works, and why it works in the context of where it's written.
Is it? We have to ask a few questions:
1. Is it actually faster on today's CPUs? (Any linear memory access pattern is going to be detected by the prefetcher)
2. Would the compiler do the same or better? eg, could it be auto-vectorizing the loop if we didn't play tricks?
3. If we really care about trading complexity for speed, wouldn't a hand-written SSE/SSE2/AVX implementation be even faster? Why not spend our complexity budget there?
In other words, there actually is an SSE/SSE2/AVX implementation in glibc.
This copy in plain C is the fall-back to if the porter didn't implement strlen in assembly for the architecture they were porting to.
It is a reasonable guess at a somewhat architecturally-independent fast implementation. If someone really cares about squeezing all the performance they could out of strlen, they implement the assembly version.
Beyond that, many architectures that gcc supports don't include prefetchers, vector units and all the rest. The world is not all x86.
2) Mostly not. gcc and clans don't vectorize "search loops" i.e. loops that terminate early based on some condition. These loops are tricky to vectorize at least partly because of the reading-beyond-the-end issue mentioned in the accepted answer. icc does vectorize some search loops, not sure if it would do a good job on this one. I'm not sure about MSVC, but it's usually way behind on everything optimization related so I think we can assume not.
3. Yes definitely. glibc has such implementations for popular platforms like x86, so this code isn't actually being used on your PC say.
For deep in the bowels of a compiler or libc, where developers might think it's useful to optimize code that has to be run in a huge variety of impossible-to-predict types of workloads, I'm more sympathetic, but it's objectively not good code. It might be useful and necessary in this very very narrow context, but it's far too clever to be good.
The answerer may have been a bit heavy-handed in knocking it down, but I think it was entirely appropriate when helping to educate someone who is new to C.
I agree that the other answer you link to is probably better, with the caveat that I'm disappointed that there's no warning against writing code like that in the general case. The sentence that starts with "They make assumptions..." is IMO not strong enough to point out that the strlen() code referenced relies on implementation-defined behavior and is not even remotely portable C.
This is tangential to the meat of your comment but I feel compelled to nitpick based entirely on personal anecdote: I have been helped hundreds of times on StackOverflow by people who had nothing to gain from it and yet provided in depth, insightful answers. In my experience, the farther you get away from the big, overwhelmed tags, the better the quality is. But you don't want to get so obscure that you are just ignored.
The Racket community on SO is particularly fantastic, and (in my experience) the more 'web' related your question is, the worse answers you get.
I would never take an answer on SO w/o a grain of salt w/o reading comments.
There is nothing wrong with the simpler version, but it’s not as fast (for longer strings).