1 Answer
1

Provide options to reduce on-disk and in-memory footprint:
As long as you want to keep binary compatibility to glibc these options are useless or have nearly no effect on x86-64.

Support cross-compilation and cross-validation:
Well... Who does cross-compiling for x86-64...

Support processors used in embedded systems:
I guess you don't run "x86-64" embedded systems, so it's useless, too.

Incorporate support for processor-specific functionality where appropriate:
glibc already has full optimizations for x86

Retain API and ABI compatability with GLIBC wherever feasible.

I wouldn't suggest using eglibc unless your distribution fully supports it, otherwise you may sometimes break linking when full ABI compatibility is not possible.
Though, many developers criticize the development-style of glibc and so non-technical reasons may favor eglibc over glibc.

API and ABI compatibility between eglibc and glibc disallow big changes and all x86-64 optimizations are probably merged into glibc, too.