I'll start. TL;DR: It's probably OK.
P-256 and P-384 seem to be the most widely implemented and/or preferred "curves", probably because they are the two selected for http://en.wikipedia.org/wiki/NSA_Suite_B and the right size for strengths currently considered comfortably safe.
To be pedantic they are really parameter sets consisting of a curve over a field plus a generator of a large subgroup, but everyone just says curve for convenience; the algorithms such as ECDSA and ECDH are the same for all curves and keys, just as the algorithm RSA is the same for all keys.
P-521 is the largest curve currently standardized for SSL/TLS, which satisfies size maniacs.
ECC smaller than 160 bits is probably breakable fairly soon, and important standards prohibit less than 224 or 256 to be comfortable; see http://www.keylength.com . Binary fields have proven less popular. Thus the curves RedHat chose are likely enough for decent interoperability.
Some, notably Dan Bernstein, argue that ALL the standardized NIST/SECG curves are hard to implement without sidechannels and could even be backdoored, see http://safecurves.cr.yp.to and https://crypto.stackexchange.com/questions/12898/is-there-a-feasible-method-by-which-nist-ecc-curves-over-prime-fields-could-be-rigged , but the proposed alternatives aren't yet standardized and will apparently require changes in implementation (of an equation form that retains the sidechannel resistance) to be developed and deployed widely enough before they become useful, so don't look for that tomorrow.
But if you want, I think there should be nothing wrong with using your own completist build, as long as the upstream OpenSSL version new enough to contain needed security fixes isn't so new it's incompatible with what your other RedHat/CentOS packages expect.