Earlier quoted context omitted.
I'm not saying that all change should be avoided. I'm saying that all change is an annoyance to your users, all change has a cost. So if you do want to force your users to change, provide them with an escape hatch so professionals can avoid that, or be really certain that the change is genuinely making things better. Imagine that every change you're making is like hitting your user in the face with a brick. If you're…
I'm saying that all change is an annoyance to your users, all change has a cost. Except for the changes like "reduce memory usage" or "fix crash when X happens" --- those are true improvements.
To expand on your point, how many bugs and crashes do we tolerate in software simply because rebuilding features has priority over refining features or handling more edge-cases?
Slack's new interface isn't just different, it's buggier. Stuff like copy-paste is broken. So it's not just that we have to adapt to a new workflow, we're also accepting a lower-quality piece of software that is less reliable than what we had before. And in theory a refactor or rewrite might be so valuable that I could tolerate that, but I don't see that value here.