Incidentally I'd say no, it probably wouldn't be great to have this in routers as the tests its performing can potentially be quite invasive, at least the regular speed tests.
Nobody wants a random speed test performing in the middle of watching Netflix or worse, making a VoIP call, video conference, working from home or gaming. Plus it would be a huge waste of backhaul bandwidth, how would you schedule it so you don't suddenly have 100s or 1000s of customers all maxing out the lines at the same time? You'd jam up the network quite quickly.
The samknows setup does have solutions in place for both those issues. The test running is triggered centrally, so they control how many tests are running simultaneously. Otherwise the tests would be meaningless as they'd easily eat up all the test server capacity. And when a test is requested centrally, the Samknows agent has the option to abort the test if it detects significant other traffic. This seems to work well. On my unit there is a long list of tests the device refused to run or aborted because of user activity. Of course over time for watching long term trends it doesn't matter.
Plus the schedule could be extremely sparse, unlike the one deployed at the moment in my unit for following a reported performance issue. My ubiquiti triggers a speedtest once per day. You don't even need to do them that often.
In short, I don't think any of the reasons you mention are reasons not to do it, I think they're just things to be aware of (that it looks like the Samknows team have already considered).
I understand there are already some routers that may have built in the Samknows tech (though I think this may only be the Realspeed portion for doing on demand tests from the router instead of from the browser).