Can't speak about your experience, but I had very little (aka zero) unfixable issues with ath9k under OpenWrt. That is, I ran into some power saving issues that made the connection to stations drop under some repeatable circumstances, but managed to help the developers find and fix the bug (by doing extensive testing leg work). Not sure how/if proprietary drivers would have been any better here and if proprietary developers would have spend as much time with a single end-user to debug the issue?
That is not denigrate your experience with a different chipset, and it also does not say that others will have zeros issues with ath9K, but it puts some perspective to the claim proprietary is always "better".
I remember that I only got into this whole run your own OpenWrt on a router because my mac laptop did not get reliable wifi connections with a cheap netgear router (IIRC) with the proprietary software... Not exactly sure who was to blame Netgear, or Apple, but switching to OpenWrt based CeroWrt at the time (on different netgear hardware) made that issue go away. Again that is just a single anecdote, but it illustrates that this is a messy issue with no simple rules like X always better than Y or vice versa, no?
Take a look at MikroTik.com
They e.g. use IPQ4018, but MikroTik doesn´t pay for the vendor´s driver. Their developer don´t use the IPQ4018 or 802.11 linux kernel module. They write everything one their own.
The result:
- No MU-MIMO
- No airtime fairness
- No 802.11k
- No 802.11r
- No 802.11v
- No ...
I guess Mikrotik driver can handle lots of clients under pressure unlike OpenWRT which most likely will run oom on a hAP ac2/cAP ac, speeds surely will be miserable since they're already worse than OpenWRT with a low amount of clients.
Pretty much every user's experience is anecdotal, since most people don't have dozens of routers setup for continous testing at home, therefore from a statistical standpoint it's hard to draw any conclusions. However, we have to work with what we've got.
Out of every router I've tested (and there weren't many of them, ~15 at most) on stock firmware I had issues with two and they clearly were'nt caused by wifi drivers. One of them had the worst firmware I've ever seen and the other had OOM issues due to 16 MB RAM.
When it comes to OpenWRT I've used ath10k (2,4 GHz only AP worked pretty well, had to replace it due to 4/32), rt2800 (I think, this one is confusing; the chip is MT7620, but it's not managed by mt76, so it's rt2800 or rt2x00, not sure - this one I can't setup as a repeater) and mt76 (5 GHz - issues like radio becoming inactive, couldn't change channel, packet loss and ping spikes).
That's 2 out of 3 misses - doesn't make me optimistic. I will pick up an ath9k device in the coming days to see how it works.
@hmpfe
Mikrotik is a weird one. In general, if you're interested in router firmware, you have a dilemma - new kernel + open source iffy drivers or old kernel + solid closed source drivers. And then Mikrotik comes along and offers you old kernel + iffy closed source drivers 
Of course consumer routers aren't really their focus (although they're moving more in that direction).
The latest 7.1beta2 firmware uses 5.6 kernel + their sh**** wifi driver
Off course that they use drivers provided by Qualcomm, its not like they write them.
They only do minor customisations so that drivers understand their regulatory databases and caldata compression.
Other features dont have anything to do with the driver, but with the AP daemon that doesnt support them.
@robimarko
It´s hard to believe, but MikroTik really writes their own wireless driver. MikroTik regularly confirms this in it´s forum, e.g.:
https://forum.mikrotik.com/viewtopic.php?t=145047#p713800
"You are right, that MikroTik made wireless driver doesn't have Wave2 support, so new chipset benefits are not there. We are working on a new driver."
They use their own wireless driver package, which is independent from the linux kernel:
https://forum.mikrotik.com/viewtopic.php?t=153685#p761102
"Since at the moment v6 and v7 uses identical driver and software for wireless, your observation is most likely a coincidence. The performance should be the same, signals also."
https://forum.mikrotik.com/viewtopic.php?f=2&t=145047&p=742089&hilit=reinis+mu+mimo#p741741
"Most of the features are implemented, but MU-MIMO is WIP"
Sounds a bit like the comparison of my (very) old Merc to my new one. The old one did not have so many bells and whistles, but it simply ran ...
Wave2 being WIP for more than a year it's a signal of the driver being written by them (not the firmware which should be the QCA provided) otherwise they could just deprecate their old AP daemon in the development branch for beta testing purposes
Amen, that is requirement #1 for any networking solution, all the rest is gravy, or meaningless if absent.
Even the most widely supported Atheros platform, the Archer C7 has been suffering from flaky Wifi ever since 18.06.x (I have a fleet in varied deployments).
MT76 is supposed to be very well supported due to more extensive OpenSource implementation, and it does have very nice features and smooth performance (when working). But suffers from lack of stability/reliability when running under load for hours.
I would love to be able to do more than just complain about issues I see and report useful data to the dev's, but I'm not aware of a decent guide for the more technical users (but not devs) to follow to capture the information that would be useful in resolving the problems. Stuff like what system vars to capture, log-levels for the various elements, etc.
For instance: How to tell the AP is 'stuck' and what data needs to be gathered, then which process needs to be restarted?
That might even be helpful in creating a watchdog script to 'unstick' current flaky wifi.
Thumbs up for ath9k. Here's Felix Fietkau on the state of wireless drivers and he explains what went into making ath9k soooo good. Yes it's old, but he gives a good summary of different wireless drivers as well. He's the main developer on mt76 (the best successor to ath9k hardware in terms of stability in my opinion). What a rock star, wish he gave more talks. 
@BenSisko Stability? Look at this https://github.com/openwrt/mt76/issues and how support for older devices look like. Older chips are almost forgotten with remaining bugs.
My opinion is the same will happen with mt7615 (and eventually mt7915, in the future).
Hmm that sucks. Didn't realize the older devices were getting left behind. Is there a driver/hardware platform you prefer?
That issues list is misleading since the mt76 covers a multitude of devices, all of which report issues to the same place.
Support for a device will go for a long as there is someone who wants to maintain it. Even the 4/32 devices could be maintained to receive security updates backported to a version of OpenWrt they can run - but only if someone wants to invest the time and effor to do so. And if it happens, it'll be someone like you @BenSisko who does it for their own device because no one else has, and if someone else happens to get use of it, well, that's ok too..
I just added OpenWrt support for a device that was 1 of less than 500 and the ODM went under in 2015 :D. Doesn't mean it can't be supported.
I totally agree. I can't say objectively if one driver has less issues then mt76 but my sense of it is that at least like you said with community effort and interest, all of these issues can be addressed because of mt76's openness. At least we're not stuck with a binary blob from some corporation that we can't hack away on. Would be interesting to see a comparison of other driver issues that are a result of blobs. Thanks for making openwrt a little more ubiquitous.
Sounds like a good reason to stay away from Qualcomm products.
Do other vendors have the same predatory practices?
Good luck with boycotting Qualcomm, if you dont like FW blobs then except for mt76 which is most open and even it has blobs there is no choice
It's still better than Broadcom selling WiFi drivers to DD-WRT and providing no usable kernel driver for softmac chipsets
I know it's wandering off topic, but with MT being as "supportive" of the aftermarket firmware community, has anyone actually out-reached to them about testing their home-grown drivers as they Pre-release and dev them? Nothing breaks code faster than a user touching it, and they might be open to the assistance.
Aren't they already substantially contributing to mt76?