The question is, what will you do if there is a fundamental disagreement between the operational requirements for replacing the OSM software stack and your vision for OSM-NG? Would you be willing to compromise and make those changes?
Here’s one huge likely blocker:
Any new implementation of the API realistically needs to be able to run in parallel to the old one initially to have some kind of trial and transition period. Having one big switchover day where all OSM servers are stopped, the database is migrated and then started again with a completely new implementation that has never been tested at that scale is extremely risky and should only be done for very good reasons.
The core architecture of OSM-NG seems to be incompatible with this.