Three lines, eh?
- Routing a packet requires the NIC to interrupt the kernel with new data, the packet to be read from the NIC into memory, firewall rules to be run, routing determination to be made, firewall rules to be run, NAT, which requires more lookups and often creating a new packet header and checksum, firewall rules to be run, pushing the (modified) packet out to the NIC
- Consumer-router SoCs and switches handle much of this in very custom "ASIC" hardware in the switch that can only do that in one way -- the way that gets good benchmarks from reviewers at the lowest price
- Adding in SQM or other desirable features that require CPU intervention basically means that ASIC can't be used
So the bottlenecks are primarily
- CPU for interrupt servicing
- CPU for packet processing
- On some routers, bandwidth between the switch and the CPU (a single, "GigE" pathway can't support symmetric gigabit rates)
(Memory and bus bandwidth may be issues with slower clock rates)
An x86_64 board in the mid- or upper-range likely can handle gigabit symmetric routing.
The J1900 probably isn't a good choice today as there are better options available at comparable prices. I've run them in the past, and that SoC/mobo, in particular, has some significant issues. I would consider an ODROID H2 (and have one on the bench and on my list to retire my last J1900).
The Archer C7v2 was great in its day, but like most/all single-core, MIPS-based devices, isn't up to gigabit rates. You can probably get 300 Mbps through it without SQM, no wireless, on the bench. Adding in SQM and you're down around 150 Mbps. Enabling "flow offload" pushes those up a bit, but nowhere near gigabit rates, even in one direction. Using wireless is going to drag those numbers back down.