It was not done on a whim. The author and the reviewers felt that the improvements outweighed the cost of the workflow change, which they explicitly discussed. That doesn't mean they got it right, but it's completely unfair to characterize it as "on a whim". Of course, you would not know this from the article - it's misrepresenting the discussion as it happened. In particular, while it correctly points out that a reviewer raised the issue and the patch author brushed it away somewhat, it fails to mention that the reviewer actually agreed with them afterwards.

I think that the core problem is the article author saw a change that broke their workflow and didn't investigate any further for why it was made. They simply assumed they knew better and got annoyed that others saw some value in the original change. The very way it is presented in the article - as a change to add a confirmation for register overwrites - is a misunderstanding. The actual purpose of the change was to make C-g, the Emacs "cancel" key, work with register commands. The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.

Do you do a lot of emacs development? I certainly don't. I'm trying to piece together who here is talking about the norms of the Emacs development team and who's talking about their opinions of how software engineering should work everywhere.