When you don't define "done" early, you often end up defining it under pressure, close to the release.
That's a terrible time to do it because that's when the decision becomes the most expensive and people the most unreasonable.
Days before the release, "does this need fixing" becomes tangled with roadmap commitments, customer promises, stakeholder expectations, engineering capacity, QA time and the emotional fact that everyone is tired of looking at the thing and wants it done. They just don't know what done means.
So they can't think straight any more, they become unreasonable and accessibility gets messy.
If you've never agreed what "done" meant for the feature, you now have to decide whether you should postpone the release. If the acceptance criteria never said what must work for the user, you now have to debate whether the flow is really finished. If ownership was unclear, you now have to find someone with authority to make the call.
Mind you, none of that is impossible on its own. But taken together, it's damn near impossible. It's slower, louder and more political than it needs to be.
The thing is, that missing definition of done doesn't disappear. It lies and waits. At just the most inopportune moment, it surfaces as a release meeting where everyone is trying to make a quality decision while also trying not to move the release date.
And that's one sure way to get rework.