There can be numerous of reasons why something 'has' to be changed. These changes are not always justified from some perspectives of course. If these perspectives represent the majority and also on the long run, something's wrong and perhaps that is your point. But sometimes, change is for the better, for the majority, especially on the long run. Often, with software design, you reach local optima, and to get further (more user friendly, more flexible, incorporating new or changed features, adapt changes in hardware, or things happening outside, etc), you'll need to move away from the sweet spot the majority settled with to get to another (hopefully better adjusted) local optimum.
Finding examples of cases where this did not work are no argument against all changes.
And as far as people not liking change. This is not only about re-learning. Change on itself is often met with tough resistance. And this resistance is often rationally hard to justify. Your example may or may not be like that (I don't have enough perspective to tell), but perhaps re-learning would have been more than compensated by the amount of time saved due to new features.
Of course this is always possible in general terms. But I was talking about a specific set of cases: redesigns of UIs that already work and that already have a huge base of existing users who will have to relearn what they know. In my experience, it's extremely rare for that kind of change to be "for the better".
you'll need to move away from the sweet spot the majority settled with to get to another (hopefully better adjusted) local optimum.
And in the process, you will have to move through a "pit" of UI suck where lots of people have significantly worse productivity for a significant period of time. And for what?
Finding examples of cases where this did not work are no argument against all changes.
I didn't argue against all changes; as noted above, I was talking specifically about software UI changes that force existing users to re-learn things for no good reason.
perhaps re-learning would have been more than compensated by the amount of time saved due to new features.
How much time saved? And how long before that savings pays back the huge cost of the switch, per the above?
And can these numbers even be measured anyway? Sure, Google can measure to the millisecond how long it takes for you to move the mouse from one place to another, and no doubt they have numbers to show that the new GMail UI shaves critical milliseconds off certain common operations. But can they measure the frustration caused by changes like this? Can they measure the emails that don't even get written because people get fed up with their new UI? Can they measure the cost of keeping people within their walled garden?
This problem is not limited to Google, of course; I think it's endemic in the software UI world. I think software UIs are like fashions: changes are largely driven not by functionality but by an arms race for users' attention.
Finding examples of cases where this did not work are no argument against all changes.
And as far as people not liking change. This is not only about re-learning. Change on itself is often met with tough resistance. And this resistance is often rationally hard to justify. Your example may or may not be like that (I don't have enough perspective to tell), but perhaps re-learning would have been more than compensated by the amount of time saved due to new features.