It’s hard to pinpoint the rationale to a single thing. We observed a handful of things that led to us deciding to remove the “bump on edit last post” behavior.
In the case of minor edits, it’s unnecessary noise, as you mentioned.
But even in the case of major edits, we observed it’s also difficult to explain and often unwanted. We saw people often reach for the “reset bump date” feature when they hold that power after a major edit to a documentation topic, for example. Especially when multiple topics were being edited, but even for single topic edits. We even had people flag posts telling us to do this when we hadn’t bothered to do it ourselves.
But “reset bump date” isn’t too discoverable. People would ask how to do that, signaling that they really didn’t want to bump things but hadn’t figured out how to prevent it, and that likely many who hadn’t bothered to ask faced the same problem.
Another observation was people incorrectly assuming others would see their major edits. They’d create a stub post and edit it as they worked on it. They’re confidence that others would be following along was boosted by the bump. But in reality, many who followed along with the topic didn’t bother to check because the topic still doesn’t show up as unread after edits. So an extra reply to explicitly call out revisions and ask for review or feedback in these scenarios was often necessary anyway, but wasn’t happening.
I’m pretty confident that things will eventually be easier to understand without this functionality, but we’ll need to address a couple of these cases where people had come to depend on it.