I run some tests. The latest firmware does not seem to solve the problems. I even tried https://github.com/openwrt/openwrt/pull/626/files that is actually a little better than the current master but still not ideal. I think the code in that PR is on master now (See https://github.com/openwrt/openwrt/compare/b88df4a7c8f260867f3213fc3baaa4b509d449bf...de1c58a64bd66319e770d2587da07d8c9c90174a) but other code and other changes are there as well.
When I went back to one of the latest releases of original firmware by Xiaomi, the router seemed slower than it used to be. I had to install an older version of the original firmware by Xiaomi to get closer to the speed I used to get. And it still seem slower.
Just running the new firmware may had altered some calibrations stored on the chip. I am not sure how the MT7620 works. Considering I had worse performances in newer firmware versions, I am not even sure if Xiaomi knows in details how it works. All detailed knowledge may all be in the head of one Mediatek's employee that does not work there anymore...
Regardless, when it comes to the Openwrt and Linux MT7620 driver, my understanding is that the current code is very buggy.
The code seems to have macro problems with how the queues are implemented, they used to get full and the driver was never able to recover. I think the latter problem is fixed but maybe it is not
I think another problem is that this Mediatek chip (and others) needs to be tuned by the Linux kernel. The bulk of the code in Openwrt seems shared across a few Mediatek chips but every chip needs their own specific code. I am not even sure if the 2 versions of the MT7620 (A and N) are supposed to have the same code. But almost all contributors test on the only flavor of chip that they owns. So you may have patches to improve a chip that end up worsening another. The code that should belong just in one device flavor sometimes ended up to be shared with others instead.
Because of all of that, the code is quite brittle. The whole code should be refactored. General behaviors should be identified and kept in the general code. Then each chip should implement their own behaviors. Mediatek chips are not well documented. Beside not being trivial to identify what is general and what is not, I think that this kind of changes may be perceived as a step back. Since some devices work fine, people do not want to do it.
@daniel Correct me if I am wrong. BTW, would not be better for the MT7620 having its own folder?