In short: (i) we decided to enforce a contribution mechanism because of strong support for doing so among industry partners generally over several years and among the ROS 2 TSC membership more specifically and recently; and (ii) we chose the DCO because it’s become a commonly accepted practice for open source projects. As compared to other mechanisms (e.g., a CLA), the DCO is the lightest-weight tool that appears to convince a large fraction of the likely corporate stakeholders (and more importantly, their respective lawyers) that it’s OK to use the output from and contribute to a project.
The goal here is to do the right thing with respect to preventing inappropriate contributions while having a minimal impact on the development workflow. FWIW we almost enabled a CLA for ROS 2 a few years back, but the tools weren’t sufficient at the time to avoid having a bunch of manual steps; e.g., requiring people with commit rights to be checking github usernames against a spreadsheet before merging their PRs (we tried CLAHub, but it wasn’t quite ready yet).