The Linux DCO does something very useful. It makes every contribution have an explicit licensing agreement. Want to know if a specific contribution is covered by the DCO? Simply check the commit. Want to check if an entire file is covered? Simply check the history of the file. However, this introduces a burden upon the contributors to agree for every single contribution. It also makes agreeing to updates hard to track. How does a contributor know if their sign-off on their latest commit means the same thing as their sign-off when they read the DCO a year ago? The only way to know is to re-read the DCO or blame the file that contains the DCO to see if there were any changes.
There's another major drawback to the Linux DCO though. You have to know ahead of time that you need a sign-off in your commit. How do you find that? By reading through a ton of documentation. What's the penalty for not knowing? Rebasing. Do you know what that word means to people new to git? It means that they futz around with git, create a huge mess, and potentially lose their changes along the way. Or it means they get to read a ton more documentation about how to use git. Either way, that's cruel and unusual punishment for a large chunk of potential contributors who just want a small change merged in.
The Node DCO takes the Linux DCO and removes all of its real benefits. You absolutely cannot take an implicit process that's hidden deep inside a document that the vast majority of contributors will not read and call it a certificate. I'd be surprised if a judge would rule any differently for Node's DCO than the implicit inbound=outbound licensing model that the majority of OSS projects have used for years. The Node maintainers have to be aware that "users don't read" and that an implicit DCO is doing nothing.
CLAs have their own benefits and drawbacks. The biggest benefit of a CLA is that the recovery process for not doing the right thing ahead of time is exactly the same as just doing the right thing ahead of time. You can make a contribution, then sign the CLA and you'll be fine. No need to go back and do anything else in git. However, this hints at one of the problems with CLAs: they generally extend indefinitely into the past and the future, which may be viewed unfavorably by contributors. The other problem is that they often require taking an action outside of the normal contribution process, though new systems that integrate with GitHub are becoming more popular.