That's just, like, your opinion, man; tell it to the retrocomputing folks.
IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html
It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them.
Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.
Or as it's generally said, the only software that never changes is software no one uses.