While I can't speak for AsusWRT, as I'm not an active contributor code wise to that project, or the forks...
In late 2016 thru the 1st half of 2017 - myself and a team of developers did build out an embedded distribution targeting various ARMv7A processors - including the Cortex-A9 cores similar to the Broadcom chips used in various AsusWRT devices... (the project does not support the Broadcom chip in Asus devices, as it doesn't include certain features, namely neon and vfp3/vfp4).
While I'm no longer active on that science project, I was brought back in to consult with the team - looking at the expected use cases and affected cores... cafeole supports Cortex-A7/A8/A9/A15/A17 based chips. Cafeole, for production is built on Kernel 4.4, so long term support is in place for the foreseeable future - patches have been pulled in for the kernel, and gcc is patched as well - the proper fix is also to look at all the packages and patch them on a rolling basis.
Generally though - even with embedded Linux - it's really hard to use this vulnerability expect in certain cases, and most of those cases require a couple of things...
1) untrusted applications
2) untrusted user behavior
Item (1) is easy - know the code and usage, most code behaves well - it's the untrusted code that can get in the way - this is why Web browsers are being patched up and updated, as many are operating systems of their own with extensions, plugins, and Javascript in general - this doesn't impact most embedded applications because the ability to arbitrarily load things is limited...
Item (2) - comes down to basic security hygiene - limit access to users and services - with embedded devices, it's really down to services exposed, and meltdown/spectre doesn't really change things there - with item (1) above, the code needs to get on the device in the first place, assuming that the code in place is trusted and vetted.
Exposing services on the public internet is always an opportunity with a single user as a threat surface, but that's nothing new - bad configs, default passwords, etc - the risk for AsusWRT is there is no user privilege separation, as everything runs as the same userid - but there's still process separation with trusted code - so again, AsusWRT by design is a closed system, and the items in place for a factory setup, or one by trusted third parties (
@RMerlin and similar) should be fine - I would absolutely trust
@RMerlin's builds...
One of the reasons why I started down the path of the science project that became cafeole was to deal with the security issues and concerns around the then current state of things in embedded space - while it would be nice to backport to Asus (and other consumer router/AP's), our memory and store footprint is larger than what most devices have on hand - min for the distro is 1GB ram and 8GB eMMC/SD, and that's well beyond most consumer router/AP's