Who are you quoting there? Unnecessary was definitely not what I heard. It's been very seriously discussed. In fact, the TLS Working Group had a draft - but then I think the chairs decided to consult the Cryptographic Forum Working Group at the IRTF for recommendations (despite CFRG already having said "yes, Curve25519 is basically fine" at the meeting before that).
In retrospect, this may have been a mistake. CFRG is not good at making choices. It led to months of delay and quite frankly bitter argument about recommendations for new curves. After a bit of discussion about choosing reasonable criteria, which seemed pretty straightforward at the time, it all went a bit pear-shaped.
(Disclaimer: the below is my own personal impression of events; an opinionated rant from someone involved with the process, not a precise factual recollection, which you can find - mostly - by looking at the CFRG list. Please do not quote me here.)
Microsoft Research came in with a we've-been-working-on-it-for-years 'nothing up my sleeves' curve generation method, all shiny and matching exactly what the TLS WG asked for… except amongst other things the curves didn't have complete addition laws like Curve25519 did, and their reference implementation's fast comb algorithm was very neat but they were very conveniently "unaware" that they'd filed a patent on it [or, at least, an algorithm that bears a stunning resemblance to it according to Mike, and with which I personally concur]. Despite, y'know, apparently doing a careful legal review to release it under Apache2? Hm. (Not that that'd ever impact another implementation, like say, everything not Apache2-compatible…?) We'd probably never have noticed, except for a very heated off-list thread I had the dubious pleasure to be involved in (…wow). But that patent wasn't about the curve generation algorithm itself, so apparently that was perfectly okay according to them, because you could always use a slower technique for the curves generated thus? - not that they were willing to confirm that the patent actually covered that comb algorithm, and they'll get back to us, but they never did, so Mike Hamburg disclosed it on-list just in case, and, well, yes.
Then we were going to have a nice performance bakeoff with SUPERCOP and the candidates (and to the extent that we did, Curve25519 still won at the ≈WF128 level, even with ECCLib using the patented comb).
Then the Brainpool guys and their pet hardware (with repurposed RSA multipliers) came in wanting random curves… basically, Brainpool. Pointing out they'd already got Brainpool, didn't really alleviate that, they wanted a new one and they wanted everyone to use that. That went down like a lead zeppelin. (Random curves run like pants if you don't have pet hardware with generic multipliers, by the way: grab OpenSSL 1.2 and test for yourself.)
Then agl it seems Had A Word With the MSR guys offlist; after that Discussion they did a revised curve generation draft along with the hardware people, and what came out the other end (not) coincidentally generated almost Curve25519, which was a huge change in position for MSR. A little more discussion and then it actually matched Curve25519 later, agl did a draft merging that with the 25519 draft proposed earlier!
So we now have a draft adopted for us to argue about in the next phase, which seems right now to be in even more pointless bikeshedding about whether the wire format should be little-endian (because all the existing software for this curve does it) or big-endian (because meaningless traditions in honour of dead architectures; traditions we're explicitly allowed to ignore), which by the way the TLS WG already did with their draft, and decided 'keep it as it is, little-endian'. Or, more usefully, if there's value in wire formats beyond Montgomery-x - there's always going to be trade-offs there, perhaps it depends if we're going to have the same wire format for key agreement and signatures and other stuff, and we actually don't have to so maybe we can just make the best decision for each, if we can actually make decisions that is.
And this is before even getting into signatures, which is barely-discussed and a long way from reaching consensus.
Long story short - as long as you're not baking anything in unchangeably: yes, just go ahead and implement X25519 (that's the key-exchange algorithm formerly known as Curve25519, yes) exactly as djb did it, because it's what we ought to end up with anyway. Better still, use a good, well-tested routine already out there for it; the latest donna maybe, or libsodium, or NaCl. Better use a temporary codepoint for it until TLS WG assign one. I'm guessing Rich and agl may be taking a broadly similar approach, but that's for them. It certainly wouldn't be too hard to patch in. I haven't got a clue about where we'll end up with signatures I'm afraid, so I'm just using Ed25519, like GnuPG and SSH have, which I think is Pretty Good (pun intended) but about which I know there's some disagreement.
Guh. If I sound frustrated, it's because it can be extremely frustrating sometimes! (Oh well, could be worse. Could be Wikipedia! <g>)
In retrospect, this may have been a mistake. CFRG is not good at making choices. It led to months of delay and quite frankly bitter argument about recommendations for new curves. After a bit of discussion about choosing reasonable criteria, which seemed pretty straightforward at the time, it all went a bit pear-shaped.
(Disclaimer: the below is my own personal impression of events; an opinionated rant from someone involved with the process, not a precise factual recollection, which you can find - mostly - by looking at the CFRG list. Please do not quote me here.)
Microsoft Research came in with a we've-been-working-on-it-for-years 'nothing up my sleeves' curve generation method, all shiny and matching exactly what the TLS WG asked for… except amongst other things the curves didn't have complete addition laws like Curve25519 did, and their reference implementation's fast comb algorithm was very neat but they were very conveniently "unaware" that they'd filed a patent on it [or, at least, an algorithm that bears a stunning resemblance to it according to Mike, and with which I personally concur]. Despite, y'know, apparently doing a careful legal review to release it under Apache2? Hm. (Not that that'd ever impact another implementation, like say, everything not Apache2-compatible…?) We'd probably never have noticed, except for a very heated off-list thread I had the dubious pleasure to be involved in (…wow). But that patent wasn't about the curve generation algorithm itself, so apparently that was perfectly okay according to them, because you could always use a slower technique for the curves generated thus? - not that they were willing to confirm that the patent actually covered that comb algorithm, and they'll get back to us, but they never did, so Mike Hamburg disclosed it on-list just in case, and, well, yes.
Then we were going to have a nice performance bakeoff with SUPERCOP and the candidates (and to the extent that we did, Curve25519 still won at the ≈WF128 level, even with ECCLib using the patented comb).
Then the Brainpool guys and their pet hardware (with repurposed RSA multipliers) came in wanting random curves… basically, Brainpool. Pointing out they'd already got Brainpool, didn't really alleviate that, they wanted a new one and they wanted everyone to use that. That went down like a lead zeppelin. (Random curves run like pants if you don't have pet hardware with generic multipliers, by the way: grab OpenSSL 1.2 and test for yourself.)
Then agl it seems Had A Word With the MSR guys offlist; after that Discussion they did a revised curve generation draft along with the hardware people, and what came out the other end (not) coincidentally generated almost Curve25519, which was a huge change in position for MSR. A little more discussion and then it actually matched Curve25519 later, agl did a draft merging that with the 25519 draft proposed earlier!
So we now have a draft adopted for us to argue about in the next phase, which seems right now to be in even more pointless bikeshedding about whether the wire format should be little-endian (because all the existing software for this curve does it) or big-endian (because meaningless traditions in honour of dead architectures; traditions we're explicitly allowed to ignore), which by the way the TLS WG already did with their draft, and decided 'keep it as it is, little-endian'. Or, more usefully, if there's value in wire formats beyond Montgomery-x - there's always going to be trade-offs there, perhaps it depends if we're going to have the same wire format for key agreement and signatures and other stuff, and we actually don't have to so maybe we can just make the best decision for each, if we can actually make decisions that is.
And this is before even getting into signatures, which is barely-discussed and a long way from reaching consensus.
Long story short - as long as you're not baking anything in unchangeably: yes, just go ahead and implement X25519 (that's the key-exchange algorithm formerly known as Curve25519, yes) exactly as djb did it, because it's what we ought to end up with anyway. Better still, use a good, well-tested routine already out there for it; the latest donna maybe, or libsodium, or NaCl. Better use a temporary codepoint for it until TLS WG assign one. I'm guessing Rich and agl may be taking a broadly similar approach, but that's for them. It certainly wouldn't be too hard to patch in. I haven't got a clue about where we'll end up with signatures I'm afraid, so I'm just using Ed25519, like GnuPG and SSH have, which I think is Pretty Good (pun intended) but about which I know there's some disagreement.
Guh. If I sound frustrated, it's because it can be extremely frustrating sometimes! (Oh well, could be worse. Could be Wikipedia! <g>)