"inbound=outbound" might not require any extra procedures. If a someone contributes to a project that is clearly under some license, you can assume in good faith that they have the right to publish this contribution and that they implicitly agree to the license. To remove any question of doubt for projects on their platform, the GitHub terms of service explicitly specify inbound=outbound as the default.
A Developer Certificate of Origin is not a license. It merely certifies that the contributor has the right to contribute a contribution. The DCO does not grant any extra rights that wouldn't already be granted. Instead, this creates a paper trail that protects the project. If the project is accused of infringement (e.g. because a contribution was provided without having the right to do so), the project can demonstrate that they exercised due diligence, and can name the source of each contribution.
Therefore: whether a DCO is needed does not depend on the project license, assuming there is an obvious license. A DCO is sensible for all projects that are at risk of being accused of copyright infringement. These are particularly larger projects with many contributors, or open-source projects that compete with proprietary offerings. A project may not want to implement a DCO because this extra bureaucracy turns off potential contributors, and signing a DCO could make pseudonymous contributions impossible. Maintaining records of the signed DCOs could make the project subject to privacy regulations such as the EU-GDPR.
Some projects have a DCO as part of their Contributor License Agreement (CLA) which does specify licensing terms (typically, a less restricted inbound license).