Because merging into main better exposes the proposal to a more diverse crowd and attracts needed feedback. Especially when you’re managing multiple proposed features, it’s not viable for a mass of users to check out and test those from their individual branches. Without merging fast, you can only gather opinions from people actively reviewing patches, which are a far more minority group and likely to be biased.

What kind of time? It spent around two months between the first proposal and being merged. Do you think that people would have trawled through the mailing lists and found this and given their reviews if only it had been given 1 more week?

Ultimately, the consequences of a patch, especially one that changes UX, can only really be evaluated after the community starts using it. People using the master branch of Emacs are basically those who wish to work as the QA engineers of Emacs. End-users use release branches or even pre-packaged releases from their distro.

So, the normal process for a UX change is to merge it to master in order to get comments on the impact. Based on comments, you can either revert, move behind a flag, etc.