So some guy complains that a code path in libc is slow, but refuses to actually do anything to fix it. What's noteworthy here? Besides, this particular complaint is 7 years old. Poster: is this still an issue?
I think you must be unfamiliar with the glibc maintainers during that period. They were hostile to outside contributions, to put it mildly. The only way to fix it would have been to make a fork. Which is what actually happened in the end with eglibc.
A lot of the big distros dropped glibc and switched to eglibc because they didn't want to deal with the glibc maintainers and their refusal to fix things anymore: http://blog.aurel32.net/47
Why are you automatically obliged to fix it JUST because you mentioned it? If they just didn't know in the first place then everyone would have benefited, and if they did then something was clearly seriously broken in that development community.
Besides, the glibc developers did optimize memory and string operations, and the result was that people moaned because their buggy Adobe Flash players crashed because they were relying on particular implementation details of previous un-optimized implementations of memcpy that were explicitly not guaranteed by C99.
A lot of the big distros dropped glibc and switched to eglibc because they didn't want to deal with the glibc maintainers and their refusal to fix things anymore: http://blog.aurel32.net/47