Having had to deal with too many dependencies when using gnulib in GNU Emacs, I can sympathize with Sam Steingold: it'd be nicer to not pull in lock.c, lock.h, threadlib.c merely because an application wants to use strerror. For example, I can't see Emacs using the strerror module if this problem isn't addressed.
Eric already pointed out that this locking is only needed for multithreaded apps. Also, it strikes me that most applications don't care whether perror modifies the strerror static buffer, and if that's the reason behind this change, then applications that don't care about this bug shouldn't need to pull in strerror_r, much less the locking code. Fixing this dependency creep will require some work and testing, and that's not always trivial to do. I hope someone (Sam, maybe?) can help out with that.