Not to say that it couldn't be an annoyance in terms of bandwidth contention, but I'd be a lot more concerned about what's uploaded by smart speakers than what's downloaded.

If we're talking bandwidth contention, as far as I'm aware, traffic-shaping functionality in routers for downstream traffic isn't great. We have good functionality for prioritizing and limiting traffic on the sending side of the bottleneck link. That side knows how congested the link is. With most Internet connections, though, the last-mile link is the bottleneck. That means that effective shaping is gonna have to happen on the ISP's side (and the ISP doesn't know how the consumer wants prioritization done, and there's presently no mechanism for consumers to inform the ISP), or have smarter routers on the consumer side that can make themselves the bottleneck and shape there. The latter would be nice, as one could solve ISP bufferbloat on the consumer side.

I would think that it should be technically possible for a home router to passively detect upstream link saturation by monitoring traffic and then using ECN or packet drops to preferentially throttle a lower-priority connection.

Linux monitors RTT average time for TCP connections, which one can see in ss -i output. So the endpoint kernel is going to have enough information to passively infer link saturation on the downstream side via looking for correlated RTT increases. The problem is that a given machine on a network doesn't know what other machines are doing, so it's not in a great position to infer link saturation or shape its own traffic. You'd want the router to handle it.

I don't know if NAT is typically implemented by having a router proxy TCP connections or whether the NAT table is lighter than that, works mostly at the packet level.

checks an OpenWRT box doing NAT

No entries in ss or netstat output, so I would guess not.

Still, even if the Linux kernel on a router isn't presently tracking that statistic, it'd be possible to do so.

Once you have downstream bandwidth, you have something like a rate-limited, fair, prioritized qdisc on a Linux router with the rate kept just below the point where RTTs start spiking.