Well I think that a proper implementation of "disagree and commit" differs significantly from what's described in the article.

The author seems to be suggesting that rather than discussing technical trade-offs and nuance, you instead ship whatever the other person proposes, even if you believe it is wrong, without going through the discussion.

I always interpreted "disagree and commit", at least in a healthy form, to be more about cases where, after both sides had presented their interpretation of a technical decision and both had understood the other's point of view, they still differed in opinion as to how it should be handled a meaningful way that was unlikely to be resolved from further communication. From there, rather than wasting more time on debating, simply agreeing to disagree, shipping to move on.

The key difference being that you aren't simply accepting whatever is told you, even if you believe it to be blatantly wrong, and silently shipping based on that feedback. You're actually engaging with each other and trying to solve the problem together but not getting locked in intractable arguments.

What OP is proposing seems significantly more toxic and honestly like something I would expect from someone playing corporate politics rather than trying to excel as an engineer.