It's a log of what happened in dev and supports reconstructing history to understand why something worked or didn't in retrospect. "It work when we tried it" "oh this dependency was updated in this merge commit that could have changed the behaviour"
I am not sure how this is unique to a merge commit. The commit with the dependency change still exists in the main branch. The commit should never have gotten into main branch of it failed tests. If I take a positive action to rebase, I am accepting my fate from master anyway. If I merge into my working branch instead of rebase, that historical context issue only useful for that moment in time of reconstructing history and is not useful anymore. Once a branch goes into master, I want commits to main to have a 1:1 ratio of committed code for a task to positive action taken by a human.
