Home routers come with one of three instruction set families (MIPS, ARM, PowerPC) with CPUs or SoCs from at least six major manufacturers (Broadcom, Qualcomm-Atheros, Ralink/MediaTek, Marvell, Freescale/NXP, Realtek) and WiFi interfaces from any of them except Freescale but plus Quantenna. And there are multiple generations of hardware in the market at any one time. That adds up to a hardware ecosystem that is vastly more diverse than PCs; this is in no way a narrow scope of problem. And I'm ignoring all the devices that also have a cable, DSL, or cellular modem.
The boundaries of what tasks are handled by the CPU vs by dedicated offloads on the SoC vs by the NIC (which usually has software of its own) differs with every manufacturer and every hardware generation. The job we want our routers to do is a moving target as the industry continues to develop new routing and configuration protocols (eg. Homenet) and new QoS techniques and new WiFi rate control techniques that need to be incorporated into the software running on the CPU and/or NIC. The hardware is usually weak enough that the products can only get the job done by prioritizing performance over expensive security measures.
I could get behind the idea of a line-rate dedicated firewall+NAT with formally specified behavior. But any attempt to enumerate the core functionality of a modern wireless router will leave you with a job that is far larger than any successful formally specified/verified software project.
Running atop Linux is the only option that doesn't leave you stranded with a '90s-era feature set and a cripplingly small base of supported hardware, and the userspace stuff is the low-hanging fruit for securing anyway.
Your point about the diversity of the router hardware ecosystem is an important one, and from what I can tell, makes up a significant portion of the OpenWRT project.
I think though that the "industry" work on QoS and rate control has been pretty dismal and counter-productive. The major improvements in QoS in OpenWRT didn't come from the router industry, and the router industry hasn't been speedy about incorporating it. Fixes for queuing and rate control in the WiFi stack are also coming from outside (when they come), and who knows how long they will take to get mainstreamed.
Their hardware support is not as good as Linux, especially for WiFi and for embedded SoCs. Their network stacks are lacking in more advanced features like QoS that's not from the '90s (AQM, FQ, traffic shaping that accounts for the overhead your DSL or cable modem adds) and I'm not aware of any efforts to eliminate bufferbloat from NIC drivers the way BQL has for most Linux Ethernet drivers. I'm not sure how Linux compares against the BSDs for dumb packet forwarding and NAT performance, but for real-world performance the better QoS makes it no contest.
Linux is what the chipset manufacturers target, it's what the router manufacturers ship, it's what most of the academics seem to turn to when they're not using a network simulator, and Linux seems to have the most active networking developers. The only compelling argument for BSDs is that pf.conf is more approachable than the Linux tools, but BSD advocates usually don't mention that it's because pf does a lot less than tc and the other Linux tools.
FreeBSD has QoS available via PF and ALTQ. As for performance, Netflix chose FreeBSD for their CDN for the better network performance over linux.
I do take your point about hardware support on consumer routers though - most of these are based on linux so its relatively easy to get linux based *wrt installed on them
Stop thinking like QoS has a singular meaning. ALTQ provides the aforementioned '90s-era inferior QoS techniques, and it isn't even available on FreeBSD without recompiling the kernel. The dummynet module is a little more modern, and in February patches appeared implementing the CoDel and FQ-CoDel AQMs that Linux has had for four years.
The boundaries of what tasks are handled by the CPU vs by dedicated offloads on the SoC vs by the NIC (which usually has software of its own) differs with every manufacturer and every hardware generation. The job we want our routers to do is a moving target as the industry continues to develop new routing and configuration protocols (eg. Homenet) and new QoS techniques and new WiFi rate control techniques that need to be incorporated into the software running on the CPU and/or NIC. The hardware is usually weak enough that the products can only get the job done by prioritizing performance over expensive security measures.
I could get behind the idea of a line-rate dedicated firewall+NAT with formally specified behavior. But any attempt to enumerate the core functionality of a modern wireless router will leave you with a job that is far larger than any successful formally specified/verified software project.
Running atop Linux is the only option that doesn't leave you stranded with a '90s-era feature set and a cripplingly small base of supported hardware, and the userspace stuff is the low-hanging fruit for securing anyway.