The plot thickens: Willem Pinckaers suggested on Twitter that the code as presented doesn't in fact pass Dual_EC's output through the 3DES DRBG at all, but rather (in both versions) directly exposes the output of Dual_EC.
Because, from here, it looks an awful lot like Juniper put their own backdoor in, and the hacker just changed it to let them use it instead. The use of Dual_EC alone, maybe, could be overlooked... but with an implementation bug that just so happens to reveal Dual_EC output directly... something's fishy.
There were cryptographers who could have given you a plausible reason to use Dual_EC --- all of them would have recommended against doing so, though.
But there's no practical reason.
EDIT: The conspiracy theorist in me would say "this is intentional, too." Changing a value to 31 from 32, or adding a single global assignment in a different function, wouldn't be caught on first review most likely, especially since where the '31' is, 31 is also used all over the code to refer to X9.31.