An update on m tuning attempts:
I got DFS channels working, but I had to use some questionable trick. https://github.com/openwrt/mt76/issues/925 is about DFS channels on this radio, and it points to https://github.com/openwrt/mt76/commit/f96cffa03e5789dd4ee9a219a65532841e237ccc . Editing all instances of mt7615/init.c in my openwrt build tree (I don't know which one is used in the end) to unconditionally use if_comb_radar allowed DFS to seemingly work. hostapd waits a minute when bringing the interface up, decides there is no radar, and now I can run a wifi on e.g. channel 100.
I don't know if DFS is actually working though, i.e. if it would detect a radar if there were one. Misc comments suggests that it is either not working by hardware limitation or not tested. The original firmware does not support DFS channels (an earlier comment in this thread says so), so I think my hack is not safe to use.
It also doesn't allow 160 mhz wide configurations. Setting 160mhz seemingly seems to work with the hack - hostapd says the network is up after the DFS grace period - but the network is not in fact there.
Furthermore, DFS channels are slower than the non-DFS ones. While I get about 700 mbit/sec from wired ethernet to my Mac on channel 36@80, I get only 520 at 124@80. Channel 161 is even slower, at about 40 mbit/s. Channels 157+ in theory allows slightly higher transmit power, but I haven't tested if that actually makes a difference.
So unless you want to run an outdoor wifi with this device and have a pet weather radar to test if DFS actually works, stay at channel 36.
I also played around with hardware offloading settings without success. Enabling Software flow offloading in Luci Network->Firewall does not result in any noticeable change in CPU load when transfering data between wired ethernet and wifi in either direction, nor does it change anything when NATing between WAN and wifi. It does however break nftable QoS as the description suggests.
Setting it to HW flow offloading doen't make a CPU load or speed difference either. /sys/kernel/debug/ppe0/bind remains empty. /sys/kernel/debug/ppe0/entries has some entries, but all of them show packets=0 bytes=0.
dmesg says the driver tries to load mt7663pr2h.bin, fails, falls back to mt7663pr2h_rebb.bin. The mt7615 source code suggests the former is the offload capable firmware and it is provided by kmod-mt7663-firmware-sta, which has "client mode offload" in the description. I enabled it and the mt7663pr2h.bin load failures went away, suggesting it is in use. It still did not make a difference in transfer benchmarks. https://github.com/openwrt/mt76/issues/572 suggests this package breaks the ability to run multiple APs on the 5ghz device.